On Thu, Jul 25, 2019 at 7:40 AM Johanna Amann <joha...@icir.org> wrote:
> > 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 :) 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 _______________________________________________ zeek-dev mailing list zeek-dev@zeek.org http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
