On Thu, Jul 25, 2019 at 7:40 AM Johanna Amann <johanna(a)icir.org> wrote:
script uses the last-reachable tag in "master". At the
time we start the 3.1.0 development cycle, we don't have that 3.1.0
tag, and also that tag won't ever be made along the "master" branch,
it will be made sometime later within the "release/3.1" branch.
I might be slow here - but doesn’t the same problem apply to the
proposed naming scheme?
No, provided our versioning script keeps relying on last-reachable-tag
in master, we are free to create a 3.1.0-alpha tag in master, but we
aren't free to create a 3.1.0 tag in master. That would mean we're
tagging a final 3.1.0 release way too early. We could move the 3.1.0
tag later, but in the meantime I don't want to have to communicate to
people looking at the tags that it's not really an official release
yet (e.g. GitHub will automatically start listing it as a release).
So - you proposed master using 3.1.0-alpha.X. I was
asking why we
can’t just do 3.1.0-X instead, given that in semver numbering
everything still stays consistent. I agree that this will need changes
to our versioning scripts :)
We *can* use 3.1.0-X to get a similar ordering property, but there's
reasons not to *want* to do that:
* We'd need a completely different versioning script/process, one that
doesn't rely on git tags.
* It's changing the meaning of X.Y.Z-[commit #] to mean "pre-release"
rather than "post-release".
* That potentially creates a bigger difference/inconsistency between
what sub-projects are doing for versioning.
True. I still like the sound of -dev and -rc better;
and just not having
a -alpha/-dev label even more - but I admit that that is a purely
personal preference to some degree.
My main reason for preferring alpha/beta is "it's less different than
before", otherwise don't have much argument against dev/rc.