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

[Mehdi Amini via llvm-dev]

> On Jun 28, 2016, at 4:26 PM, Duncan P. N. Exon Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 
>> On 2016-Jun-28, at 13:17, Richard Smith via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>> 
>>>> I think I agree with Chris with 3.10 being the worst possible outcome.
>>> 
>>> I'd be interested to understand why you or Chris thing 3.10 is the worst possible outcome.
>> 
>> Personally: I think it would be a bad outcome, because if we go to 3.10, I do not see when we would ever transition to 4.0. What change would be "large enough" to classify as a new major version of all of LLVM? Given that we are (presumably) going to have a "sliding window" support story for LLVM IR changes, and even LLVM IR changes are irrelevant to a significant number of LLVM subprojects (all of which share the same versioning scheme), it's not clear to me what would justify this.
>> 
>>> Chris has said it is because he thinks we'll never change the "3", but I don't understand why 3.10 is worse than 3.9 was in that respect. I happen to agree that we'll never change the "3", but I don't think this makes 3.10 a particularly bad choice.
>> 
>> We've historically gone from x.9 to x+1.0, so this sets precedent, and we seem to have the energy and motivation to discuss and possibly change our version numbering scheme right now. For me, it's just a question of "if not now, then when?".
>> 
>>> I'm seeing pretty much zero support for continuing to have a major/minor split. As such, I pretty strongly suggest that as a community we move to a single integer that increments every (time based) release, and a .N that increments with every patch release off of that branch. GCC and numerous other projects work this way.
>>> 
>>> I actually don't care at all what the number is: 4 or 40 seem fine.
>>> 
>>> 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 agree with Richard.  While I don't have a strong opinion about 3.10.x vs. 4.x vs. 4.0.x (assuming we document our *actual* bitcode compatibility promise), I think both 10.x and 40.x are actively confusing.

I can see an argument for 10.x: let’s just drop the leading "3.” And continue to number from where we are, i.e. 10.

—
Mehdi