[llvm-dev] Distinguishing trunk version number from release

[James Y Knight via llvm-dev]

On Thu, Jan 4, 2018 at 3:04 PM, Dimitry Andric <dimitry at andric.com> wrote:

> On 3 Jan 2018, at 18:24, James Y Knight via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > I'd like to propose that trunk always have a version number which is in
> between versions used by the previous release branch, and before the
> versions used in the next release branch.
> >
> > Right now, trunk is sharing the 7.0.0 number, which will also be used by
> the next release 4 months from now. Since some people use and release
> snapshots of clang from trunk (e.g. the Android NDK), it'd be helpful to be
> able to more reliably distinguish this.
> >
> > This is both confusing in general, and means that if you're writing an
> #if checking the version (which of course ought to be avoided when
> possible, but is sometimes the best answer), it is more difficult than it
> needs to be to do the right thing.
> >
> > E.g., a check like this will erroneously think that trunk, now, is Clang
> 7, and has fixed this hypothetical bug.
> > #if __clang_major__ >= 7
> > // Do something which was buggy before Clang 7.
> > #endif
>
> Yes, this is often done in the FreeBSD ports system, sometimes using the
> major version in the source, but more often in Makefiles, where the X.Y.Z
> version is condensed to just 'XY', as shown in https://github.com/freebsd/
> freebsd-ports/blob/master/lang/v8/Makefile#L36 :
>
> .if ${COMPILER_TYPE} == clang
> CXXFLAGS+=      -Wno-nested-anon-types -Wno-unused-function
> -Wno-unused-private-field
> MAKE_ENV+=      LINK=clang++
> .if ${COMPILER_VERSION} >= 34
> CXXFLAGS+=      -Wno-unused-const-variable
> .if ${COMPILER_VERSION} >= 35
> CXXFLAGS+=      -Wno-tautological-undefined-compare
> .if ${COMPILER_VERSION} >= 36
> CXXFLAGS+=      -Wno-unused-local-typedef
> .endif
> .endif
> .endif
>


That seems a very unfortunate scheme, especially considering the differing
definition of the same-named variable in FreeBSD core's makefiles:
https://github.com/freebsd/freebsd/blob/d67d8724ce34e69801d9018e6bf76afed2ca3841/share/mk/bsd.README
"""
COMPILER_VERSION
A numeric constant equal to:
     major * 10000 + minor * 100 + tiny
for the compiler's self-reported version.
"""

I don't think that's a good reason to not use X.99 for clang versions,
however -- the FreeBSD makefile can easily translate that to X9 if it
likes, or, change their definition.


> I see a couple alternatives for improving this:
> >
> > 1. Change the way we version trunk.
> >
> > After creating release branch for X.0, change trunk to version X.99
> instead of (X+1).0. Thus, trunk would always have a .99 minor release. The
> release branch would be incremented from X.99 to (X+1).0 upon creation.
> >
> > 6.99.0-------7.99.0----------------8.99.0------...
> >            \-7.0.0----7.0.1      \-8.0.0----8.0.1
>
> Probably 6.9, 7.9 and such would be enough, since 7.1 and 7.2 won't ever
> appear in the recent "new versioning scheme", and even older versions never
> reached past the .9 second level version?
>

Perhaps so, but I greatly prefer the implication that "99" has that it's
not a real version, which "9" is much less suggestive of.


>
> > 2. Change the minor version of the first release.
> >
> > Leave trunk as X.0 as now, but on the release branch, increment the
> version to X.1.
> >
> > 7.0.0--------8.0.0-----------------9.0.0------...
> >            \-7.1.0----7.1.1      \-8.1.0----8.1.1
> >
> > I'd marginally favor #2, because that's similar to how GCC is doing it
> now, but what do others think?
>
> As far as I can see, the first variant would not really work for the
> FreeBSD ports system as-is, since it has silently assumed the second-level
> version number to be smaller than 10.  But maybe I'm reading the ports
> infrastructure makefiles incorrectly.
>
> That said, as long as there is a way to identify the (end-user visible)
> clang or llvm version where certain features or bugs were introduced, both
> variants would be OK.
>
> -Dimitry
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180104/3d07ebfb/attachment.html>