(This is not for landing until we've created the 3.9 branch.)
I'm still not sure it is best to set the patch level to 0, as opposed to setting the minor version 0. Our stable releases really are patch levels. What we're really doing is getting rid of our minor versioning.
Oh, I thought the idea was to drop the patch version completely.
I suppose your suggestion (x.y.z, where y is always zero) would be a less disruptive change, but isn't it weird to have a part of the version number that we never actually use?
But if we're using the patch number, we need that in the version string, and then omitting the minor number in the middle seems very strange. Or are you really saying major=4,minor=0,patch=1 should be rendered as 4.1?
I know it seems strange, but I think it is an option we should consider. It would leave us with a somewhat-unfortunate historical artifact (i.e. it would be quirky), but on the other hand but it would also leave the semantic meaning of the fields intact at the API level. In other words, our strings would be <major>.<patch>. Maybe we could not even define a minor version at all?
I'm just worried that even if we intend the y in x.y to be interpreted as the patch version, tools and readers of the version string will still interpret it as major.minor.
But I've started to like the idea of just using x.y.z with y=0. We'd release 4.0.0, Tom would ship 4.0.1, and then we'd go to 5.0.0. I think the risk of people and tools being confused by that would be very small, and communicating that we're treating each six-month release as major shouldn't be too hard.
This just sets the version to 4.0.0, with the expectation that the next major release be 5.0.0, and patch releases 4.0.1, etc.
I like this, as it eliminates the ambiguity of what 4.1 would mean (major release like 3.1 or patch release?), and avoids the problem of trying to remove one part of the tuple without breaking clients expecting it to be there, e.g. in LLVM's config headers, Clang's built-in macros, etc.
Richard, I'd be interested to hear your thoughts on this one.
I agree with this. If our stable releases are 4.0.1, it gives us the option to create minor releases (e.g. 4.1.0) if we want. One possible use for minor releases would be to backport new features, but not change the API (I'm not saying we should or shouldn't do this, it is just an example).