llvm dev - Jan 2018 - Distinguishing trunk version number from release

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180103/bcfd4ccb/attachment-0001.html>

On Wed, Jan 3, 2018 at 12:24 PM, James Y Knight <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?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180103/9b891455/attachment.html>

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>

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
>

On 01/03/2018 02:55 PM, Tom Stellard via llvm-dev 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?
I think that the best we can do is give people some of idea of "this is 
based on a release" vs. "this is based on some other intermediate 
version." Testing revision numbers is probably not meaningful because 
you never know what other commits have been reverted or back-ported for 
a particular build.

  -Hal
>
> -Tom
>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> 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

On 01/03/2018 12:55 PM, Tom Stellard via llvm-dev 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?
Another option would be to have the -version output include the svn 
revision by default for dev builds.

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>

On 3 Jan 2018, at 18:24, James Y Knight via llvm-dev <llvm-dev at
lists.llvm.org> 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
Yes, this is often done in the FreeBSD ports system, sometimes using the major
version in the source, but more often in Makefiles, where the X.Y.Z version is
condensed to just 'XY', as shown in
https://github.com/freebsd/freebsd-ports/blob/master/lang/v8/Makefile#L36 :

.if ${COMPILER_TYPE} == clang
CXXFLAGS+=      -Wno-nested-anon-types -Wno-unused-function
-Wno-unused-private-field
MAKE_ENV+=      LINK=clang++
.if ${COMPILER_VERSION} >= 34
CXXFLAGS+=      -Wno-unused-const-variable
.if ${COMPILER_VERSION} >= 35
CXXFLAGS+=      -Wno-tautological-undefined-compare
.if ${COMPILER_VERSION} >= 36
CXXFLAGS+=      -Wno-unused-local-typedef
.endif
.endif
.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
Probably 6.9, 7.9 and such would be enough, since 7.1 and 7.2 won't ever
appear in the recent "new versioning scheme", and even older versions
never reached past the .9 second level version?

> 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?
As far as I can see, the first variant would not really work for the FreeBSD
ports system as-is, since it has silently assumed the second-level version
number to be smaller than 10.  But maybe I'm reading the ports
infrastructure makefiles incorrectly.

That said, as long as there is a way to identify the (end-user visible) clang or
llvm version where certain features or bugs were introduced, both variants would
be OK.

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180104/9b69275b/attachment.sig>

On Thu, Jan 4, 2018 at 3:04 PM, Dimitry Andric <dimitry at andric.com>
wrote:
> On 3 Jan 2018, at 18:24, James Y Knight via llvm-dev <
> llvm-dev at lists.llvm.org> 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
>
> Yes, this is often done in the FreeBSD ports system, sometimes using the
> major version in the source, but more often in Makefiles, where the X.Y.Z
> version is condensed to just 'XY', as shown in
https://github.com/freebsd/
> freebsd-ports/blob/master/lang/v8/Makefile#L36 :
>
> .if ${COMPILER_TYPE} == clang
> CXXFLAGS+=      -Wno-nested-anon-types -Wno-unused-function
> -Wno-unused-private-field
> MAKE_ENV+=      LINK=clang++
> .if ${COMPILER_VERSION} >= 34
> CXXFLAGS+=      -Wno-unused-const-variable
> .if ${COMPILER_VERSION} >= 35
> CXXFLAGS+=      -Wno-tautological-undefined-compare
> .if ${COMPILER_VERSION} >= 36
> CXXFLAGS+=      -Wno-unused-local-typedef
> .endif
> .endif
> .endif
>

That seems a very unfortunate scheme, especially considering the differing
definition of the same-named variable in FreeBSD core's makefiles:
https://github.com/freebsd/freebsd/blob/d67d8724ce34e69801d9018e6bf76afed2ca3841/share/mk/bsd.README
"""
COMPILER_VERSION
A numeric constant equal to:
     major * 10000 + minor * 100 + tiny
for the compiler's self-reported version.
"""

I don't think that's a good reason to not use X.99 for clang versions,
however -- the FreeBSD makefile can easily translate that to X9 if it
likes, or, change their definition.

> 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
>
> Probably 6.9, 7.9 and such would be enough, since 7.1 and 7.2 won't
ever
> appear in the recent "new versioning scheme", and even older
versions never
> reached past the .9 second level version?
>
Perhaps so, but I greatly prefer the implication that "99" has that
it's
not a real version, which "9" is much less suggestive of.

>
> > 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?
>
> As far as I can see, the first variant would not really work for the
> FreeBSD ports system as-is, since it has silently assumed the second-level
> version number to be smaller than 10.  But maybe I'm reading the ports
> infrastructure makefiles incorrectly.
>
> That said, as long as there is a way to identify the (end-user visible)
> clang or llvm version where certain features or bugs were introduced, both
> variants would be OK.
>
> -Dimitry
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180104/3d07ebfb/attachment.html>