[llvm-dev] Distinguishing trunk version number from release

[James Y Knight via llvm-dev]

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?
>
> -Tom
>
> >
> >
> > _______________________________________________
> > 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/fd618446/attachment.html>