[llvm-dev] Distinguishing trunk version number from release

Hal Finkel via llvm-dev llvm-dev at lists.llvm.org
Wed Jan 3 11:24:07 PST 2018


On 01/03/2018 11:25 AM, James Y Knight via llvm-dev wrote:
> On Wed, Jan 3, 2018 at 12:24 PM, James Y Knight <jyknight at google.com 
> <mailto: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?
>

I'm in favor of doing one of these two things. I have a slight 
preference for (1), because I think that will be less confusing to 
users, and prevents us from having to talk about "something point one", 
instead of just "something", as the release version.

  -Hal

>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180103/fba1bfc7/attachment.html>


More information about the llvm-dev mailing list