[llvm-dev] Distinguishing trunk version number from release

[James Y Knight via llvm-dev]

On Wed, Jan 3, 2018 at 12:24 PM, James Y Knight <jyknight at google.com> 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.
>

Oops, I misphrased that -- I meant to say "which is *after* 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/9b891455/attachment.html>