[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