Dev versioning?

[alexsnaps]

This changes the version of the crate to 0.3.0 and the binary's to 1.0.0… I've added a -dev suffix. Trying to reflect what gets build off main or other branches, but mostly not at 'tags' for actual releases… so to avoid ever having e.g. a 1.0.0 before and it released, and proposing to increment right after release re-adding the suffix. Not attached to -dev tho… just anything that differentiates it from an actual release.
@guicassolato any point of view? It'd be great to have this across all components, wdyt?

[maleck13]

would it make sense to use a something like -rc0 (release candidate 0 )

[alexsnaps]

I'm cool with -rc0 but if we do release candidates, it becomes weird: You are at -rc0 (i.e. work in progress towards whatever version it suffixes, e.g. 1.0) then you release -rc1, dev branch goes back to -rc0 so that you have -rc0 < -rc1 < -rc0… which is weird (and not how versioning order things… i.e. lexical order, hence -alpha < -beta

But with that rational in mind -dev < -rc anyways… 🤔
… -wip "largest first letter" thing I could think of just now?
... or we'd have main at 1.0.0-rc1-dev ?

[alexsnaps]

@maleck13 I also realize I may have badly conveyed my intent here: -SNAPSHOT people use in Maven

[alexsnaps]

Also, for completeness here, I tried changing the build.rs to use git tag --points-at HEAD and figure out some magic about what version it actually builds… but somehow I couldn't get it to work reliably and also thought it wouldn't address it holistically… at the limitador level, if we'd push the output to a file and use that for versioning throughout;… but what about other components? So decided to open the floor for discussion with this change first.

[maleck13]

I follow now. So we would have v0.3.0-dev. This would be an intermediary build of all the components (perhaps a nightly)? injecting the version in to the binary and also building and publishing a new image to quay. Then when we felt we were close to a release we would switch to -rc0 etc?
So installing the operator at v0.3.0-dev would install the latest -dev releases?
Ideally then this new dev version would also be tested in an environment with a set of very stable (really really stable even if that means we only have 1 or 2 initially) tests that should never fail and are red flag that something happened. I think we should look to trigger these builds automatically on a nightly basis (as a goal).
Once we go through doing it once manually, we can then look to automate it via GH actions or some other mechanism (as long as its not from someones machine).

[alexsnaps]

Then when we felt we were close to a release we would switch to -rc0 etc?

Yes, we can do releases with RCs or whatever however we see fit (including a -nightly-<date> - e.g. rust version 1.65.0-nightly (bc4b39c27 2022-08-29) or something that's then automated… if we feel we want to distribute that), I just would like some marker that means "that's a thing that's built off this branch (could be main if e.g. v1.0.0 is where that happens) but that's NOT the release…

So installing the operator at v0.3.0-dev would install the latest -dev releases?

As wrt to dependencies across components… well, that's a bit a mess with -dev (or whichever suffix we go for), as it is per definition "unstable", which would mean that you could perfectly use n-dev of one component that would end up being incompatible with n-dev of one if its dependencies. This could happen for multiple reasons:

• There is no atomic publishing of these components
• There is no atomic installation of these neither (e.g. you run n-dev of an operator than only "later" pulls in an image of e.g. limitador… that could be weeks later and as such it'd pull the last n-dev published then…)