[llvm-dev] Distinguishing trunk version number from release

[Philip Reames via llvm-dev]

+1

On 01/03/2018 12:00 PM, Robinson, Paul via llvm-dev wrote:
>
> I agree with Hal, X.99 is easier to notice as something 
> different/unusual.  It also doesn't revisit the version-naming debate 
> for formal releases.
>
> --paulr
>
> *From:*llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of 
> *Hal Finkel via llvm-dev
> *Sent:* Wednesday, January 03, 2018 11:24 AM
> *To:* James Y Knight; llvm-dev
> *Subject:* Re: [llvm-dev] Distinguishing trunk version number from release
>
> 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 <mailto: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
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


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