Hal Finkel via llvm-dev
2018-Jan-03 19:24 UTC
[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 > 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>
Robinson, Paul via llvm-dev
2018-Jan-03 20:00 UTC
[llvm-dev] Distinguishing trunk version number from release
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180103/1f81e888/attachment.html>
Philip Reames via llvm-dev
2018-Jan-03 21:22 UTC
[llvm-dev] Distinguishing trunk version number from release
+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>