Distinguishing trunk version number from release

jyknight · January 3, 2018, 5:24pm

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:

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

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?

jyknight · January 3, 2018, 5:25pm

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."

Finkel_Hal_J · January 3, 2018, 7:24pm

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

pogo59 · January 3, 2018, 8:00pm

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

tstellar · January 3, 2018, 8:55pm

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

preames · January 3, 2018, 9:22pm

+1

Finkel_Hal_J · January 3, 2018, 9:22pm

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

preames · January 3, 2018, 9:23pm

Another option would be to have the -version output include the svn revision by default for dev builds.

asb · January 3, 2018, 9:37pm

As long as it could be done in a way that doesn't trigger a huge
number of build actions, see https://reviews.llvm.org/D37272

Best,

Alex

jyknight · January 3, 2018, 10:20pm

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.

DimitryAndric · January 4, 2018, 8:04pm

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

jyknight · January 4, 2018, 10:31pm

>
> 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 The FreeBSD Project · GitHub
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:

github.com

freebsd/freebsd-src/blob/d67d8724ce34e69801d9018e6bf76afed2ca3841/share/mk/bsd.README

#	@(#)bsd.README	8.2 (Berkeley) 4/2/94
# $FreeBSD$

This is the README file for the "include" files for the FreeBSD
source tree.  The files are installed in /usr/share/mk, and are by
convention, named with the suffix ".mk".  These files store several
build options and should be handled with caution.

Note, this file is not intended to replace reading through the .mk
files for anything tricky.

There are two main types of make include files.  One type is the generally
usable make include files, such as bsd.prog.mk and bsd.lib.mk.  The other is
the internal make include files, such as bsd.files.mk and bsd.man.mk, which
can not/should not be used directly but are used by the other make include
files.  In most cases it is only interesting to include bsd.prog.mk or
bsd.lib.mk.

bsd.arch.inc.mk		- includes arch-specific Makefile.$arch
bsd.compiler.mk		- defined based on current compiler

This file has been truncated. show original

"""
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.

DimitryAndric · January 4, 2018, 11:25pm

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.
“”"

Yes indeed, it is an unfortunate difference between the base system and the ports system. I feel that the major * 10000 + minor * 100 + tiny constant is more useful, but the maintainers of the ports system decided to use a shorter constant.

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:

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.

Yes, that is certainly a good reason. The second scheme would be similar in this respect, e.g. if the minor version number is 0, it is always trunk version.

-Dimitry

Topic		Replies	Views
Clang version numbers Clang Frontend	7	74	March 7, 2015
RFC: Name the first release from a branch N.1.0 instead of N.0.0 LLVM Project release	24	2605	December 19, 2023
FYI: Version number change Clang Frontend	1	86	June 25, 2010
Trunk is now 13.0.0 OpenMP	3	83	January 27, 2021
Release/16.x has been branched LLVM Project	0	700	January 25, 2023

Distinguishing trunk version number from release

Related topics