[llvm-dev] Distinguishing trunk version number from release
James Y Knight via llvm-dev
llvm-dev at lists.llvm.org
Wed Jan 3 14:20:39 PST 2018
I don't know about others, but I _don't_ want to be able to assign an
ordering to unreleased versions at any higher granularity than which
releases which they're in between.
Automatically assigning a consistently ordered version number to different
trunk revisions is going to be difficult/impossible in general, what with
branches, different version control systems, or even private branches in
private repositories in different version control systems, so I don't
really think it's a good idea to start going down that road.
On Wed, Jan 3, 2018 at 3:55 PM, Tom Stellard <tstellar at redhat.com> wrote:
> On 01/03/2018 09:24 AM, James Y Knight via llvm-dev 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.
> > 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?
> These proposed solutions only help distinguish between clang trunk and
> a clang release branch, but does not help to distinguish between today's
> trunk and a month from now trunk, which people using snapshots might
> care more about.
> What about adding a define like __clang_svn_revision__ instead?
> > _______________________________________________
> > 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...
More information about the llvm-dev