[llvm-dev] [lldb-dev] [cfe-dev] [Openmp-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

Hans Wennborg via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 28 13:38:06 PDT 2016

On Tue, Jun 28, 2016 at 1:17 PM, Richard Smith via lldb-dev
<lldb-dev at lists.llvm.org> wrote:
>> If 4 seems too confusing, and 40 seems too extreme, how about 10.
>> Seriously. It seems exactly as good as any other integer to start counting
>> rationally, and won't confuse people by looking like a 4.0 release.
> I think going to 10 or 40 is likely to be confusing, because there'll be two
> different ways to refer to the same version (people will say 3.10 when
> referring to version 10, or 38 when referring to version 3.8, respectively).
> This happened to Java in the version 1.6 / version 6 numbering transition.
> In order to preserve numbering continuity and minimize confusion, if we go
> from three-component versions (major.minor.patch) to two-component versions
> (major.patch), I would suggest we go from x.y.z to x+1.0. (This is also
> consistent with how GCC handled the transition.)

I haven't followed how this worked out for GCC, but I worry that if we
go from 3.9.0 to 4.0 with the intention of doing 5.0 next, users will
get confused when we ship 4.1 as a "dot" release instead of a major
release like we've used to.

There's also the question of how to practically go from a 3-tuple to a
2-tuple. Should we drop it from the version string and dir names in
Clang? Do we drop __clang_patchlevel__ or just leave it at zero? I see
GCC 5.4 is actually versioned as 5.4.0 so maybe that'd be the way to
do it?


More information about the llvm-dev mailing list