Roadmap (Suggestions)

[hasezoey]

Currently the project has seen many changes and will likely see some more re-structures in the (hopefully near) future, so here is a roadmap on how we could handle this project and agree and some rough events

• release 0.1.0, after Question about upstreaming changes from fork #56 (and likely some fixup PRs) are resolved
  • this would differentiate it from the 0.0.x line, because the internals have changed quite a bit
  • it would also mark this project as being a little more stable (though with changes expected)
  • ensure the publishing CI works (see Publishing via CI #71)
• release 0.2.0 with some other big changes (like Add filter() fn, update pagination() fn #103, Improve Code generation #105 and Simplify table config fetching logic #99)
• release 1.0.0 once we are confident the code is in a good state (and the CI is working)

what do you think @Wulf, anything to add / change?

[Wulf]

hey @hasezoey, thanks for making this list :)

We don't need to group changes like this as long as we're following semenatic versioning. I prefer pushing out things as they're merged in. I'm okay if you create a release right now.

[hasezoey]

We don't need to group changes like this as long as we're following semenatic versioning. I prefer pushing out things as they're merged in

i know, i was just trying to get a opinion on starting with 0.X.0 instead of continuing 0.0.X and not directly going to X.0.0 until everything big in the issues is done (like the refactors of options and switching of templating and testing publishing)

[Wulf]

Ah, understood! Sure, I don't mind starting 0.X.0.

[Wulf]

#111 should make things more stable

[hasezoey]

after #111 and #114, how about releasing 0.2.0 0.1.0 to get some feedback on the changes and the experimental filters?

[Wulf]

sounds good -- let's drop #111 in favor of #114. I don't want to maintain examples as well as compilation tests

[hasezoey]

sounds good -- let's drop #111 in favor of #114. I don't want to maintain examples as well as compilation tests

i dont see a reason why #111 would be unnecessary, it showcases how to use dsync as a library; though i would recommend to maybe make it one example instead.
OR we direct users to see main.rs instead?

[hasezoey]

i think the next version (0.1.0, unlike my earlier mistaken(?) message) would be ready to be done, i would just suggest merging #131 for some small clean-up in documentation

@Wulf if you have the time, could you merge it and then release a version?

[hasezoey]

@Wulf bumping this as it has been quite a while, a release is ready to be published but there are some open PRs that would be great to have before the next release.

EDIT: those PRs have been merged thanks to a review from @longsleep

[Wulf]

hey @hasezoey, thanks for your patience here.

I'll release 0.1.0 now.

[Wulf]

could you give this a look? #137

Also, just to confirm, we want to manually release this time and will use semantic-release for 1.0, right?

[hasezoey]

Also, just to confirm, we want to manually release this time and will use semantic-release for 1.0, right?

yes, manually release 0.1.0 as semantic-release does not work with 0. releases according to the FAQ (i have not actually tested it, so i assume it would either error out OR apply non 0. rules)

[Wulf]

Released 0.1.0 🚀

Again, thanks for your patience.

[hasezoey]

Great, now the major stuff is out of the way. Note that because i didnt see the git tag for this version, i have added it.