[llvm-dev] Distinguishing trunk version number from release

James Y Knight via llvm-dev llvm-dev at lists.llvm.org
Wed Jan 3 09:24:19 PST 2018


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

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

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180103/bcfd4ccb/attachment-0001.html>


More information about the llvm-dev mailing list