Page MenuHomePhabricator

Bump trunk version to 4.0 and switch to new versioning scheme
ClosedPublic

Authored by hans on Jun 28 2016, 4:12 PM.

Details

Summary

(This is not for landing until we've created the 3.9 branch.)

Diff Detail

Repository
rL LLVM

Event Timeline

hans updated this revision to Diff 62148.Jun 28 2016, 4:12 PM
hans retitled this revision from to Bump trunk version to 4.0 and switch to new versioning scheme.
hans updated this object.

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.

hans added a comment.Jun 28 2016, 4:48 PM

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?

In D21821#469421, @hans wrote:

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?

Yes.

I thought that we might just omit the minor number from the canonical string form, while taking it, at an API level, to be zero.

hans added a comment.Jun 28 2016, 6:15 PM
In D21821#469421, @hans wrote:

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?

Yes.

I thought that we might just omit the minor number from the canonical string form, while taking it, at an API level, to be zero.

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?

In D21821#469511, @hans wrote:
In D21821#469421, @hans wrote:

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?

Yes.

I thought that we might just omit the minor number from the canonical string form, while taking it, at an API level, to be zero.

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?

hans added a comment.Jun 29 2016, 8:37 AM
In D21821#469511, @hans wrote:
In D21821#469421, @hans wrote:

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?

Yes.

I thought that we might just omit the minor number from the canonical string form, while taking it, at an API level, to be zero.

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.

In D21821#470035, @hans wrote:
In D21821#469511, @hans wrote:
In D21821#469421, @hans wrote:

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?

Yes.

I thought that we might just omit the minor number from the canonical string form, while taking it, at an API level, to be zero.

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.

I think this is a good option. It also leaves us free to generate a true minor release at some point in the future should we decide to do so.

hans updated this revision to Diff 62242.Jun 29 2016, 10:53 AM
hans added a reviewer: rsmith.

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'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.

I think this is a good option. It also leaves us free to generate a true minor release at some point in the future should we decide to do so.

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).

This revision was automatically updated to reflect the committed changes.