Zeek 3.0.0+ "master" versioning process change

I'm suggesting a small change to our usual development and versioning
process of the "master" branch: replace post-release versioning with
pre-release versioning. E.g. once we enter the 3.0.0 beta period,
"master" will start using versions like 3.1.0-alpha.X where the old
process would have used 3.0.0-X (where X is number of commits since
the git tag).

Full description: https://github.com/zeek/zeek/issues/488

Please raise any potential issues soon if you find any.

- Jon

Hi,

I generally like this - the only thing that I am not sure about is the alpha label.

I get that it works great with alphabetic ordering - but for me alpha tends to signify some kind of test release. Could we perhaps make it -dev? :). If we then use -rc instead of -beta we have alphabetical ordering again - and to me this tends to represent what we are doing better in any case…

Johanna

Actually, thinking about it some more - could we just not have the -alpha (or -dev) label, and go back to how it was before - with a changed meaning?

so - just 3.1.0-[commit-number] for the development builds. This would still work in a sem-ver style since…

3.1.0-12 < 3.1.0-beta.1 < 3.1.0

if I understand the semver standard correctly. (Numeric identifiers always have a lower precedence than non-numeric identifiers; it also works on a ascii-compare).

Johanna

Actually, thinking about it some more - could we just not have the
-alpha (or -dev) label, and go back to how it was before - with a
changed meaning?

so - just 3.1.0-[commit-number] for the development builds.

Our versioning 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 generally like this - the only thing that I am not sure about is the
> alpha label.
>
> I get that it works great with alphabetic ordering - but for me alpha
> tends to signify some kind of test release.

What's meant by "test release" here ?

Could essentially consider any given commit in "master" to be a "test
release" -- and if we decide to be more formal/vocal about providing
builds of "master" (e.g. the OBS nightlies), then "alpha" may describe
exactly what you think it signifies ?

- Jon

Actually, thinking about it some more - could we just not have the
-alpha (or -dev) label, and go back to how it was before - with a
changed meaning?

so - just 3.1.0-[commit-number] for the development builds.

Our versioning 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?

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 :slight_smile:

I generally like this - the only thing that I am not sure about is the
alpha label.

I get that it works great with alphabetic ordering - but for me alpha
tends to signify some kind of test release.

What's meant by "test release" here ?

Could essentially consider any given commit in "master" to be a "test
release" -- and if we decide to be more formal/vocal about providing
builds of "master" (e.g. the OBS nightlies), then "alpha" may describe
exactly what you think it signifies ?

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.

Another advantage of them is that they keep the version numbers somewhat shorter :slight_smile:

Johanna

Using "3.1.0-X" would also feel semantically a bit confusing I think
as we'd be changing the meaning of a scheme we're already using.

I like the idea of using "dev.X" and "rcX". I was originally feeling
similar about "alpha" but the sorting is a nice property to have.
Swtiching from "beta" to "rc" would address that.

In the end, either scheme works for me.

Robin

I like -dev and -rc more as well. -alpha on the master branch seems weird to me. I feel like alpha implies we actually did an official branched release, and not just commits from the main line where we’re doing development.

Tim

> Our versioning 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 :slight_smile:

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.

- Jon

Let's just do dev/rc then, seems that's what more people prefer. And
then we'll go ahead with your scheme for 3.0.0, that should work well.

Robin