[llvm-dev] Distinguishing trunk version number from release

Dimitry Andric via llvm-dev
Thu, 04 Jan 2018 20:04:40 -0000

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


> 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?


> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180104/9b69275b/attachment.sig>