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

Hal Finkel via llvm-commits llvm-commits at lists.llvm.org
Tue Jun 28 18:24:59 PDT 2016


hfinkel added a comment.

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?


http://reviews.llvm.org/D21821





More information about the llvm-commits mailing list