[PATCH] D21821: Bump trunk version to 4.0 and switch to new versioning scheme

Hans Wennborg via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 29 08:37:28 PDT 2016


hans added a comment.

In http://reviews.llvm.org/D21821#469527, @hfinkel wrote:

> In http://reviews.llvm.org/D21821#469511, @hans wrote:
>
> > In http://reviews.llvm.org/D21821#469443, @hfinkel wrote:
> >
> > > In http://reviews.llvm.org/D21821#469421, @hans wrote:
> > >
> > > > In http://reviews.llvm.org/D21821#469406, @hfinkel 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.


http://reviews.llvm.org/D21821





More information about the llvm-commits mailing list