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

[Hans Wennborg via llvm-dev]

On Tue, Jun 28, 2016 at 5:22 PM, Duncan P. N. Exon Smith
<dexonsmith at apple.com> wrote:
>
>> On 2016-Jun-28, at 16:22, Hans Wennborg via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>>
>> On Tue, Jun 28, 2016 at 2:37 PM, Chris Lattner via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>> On Jun 28, 2016, at 12:55 PM, Chandler Carruth via Openmp-dev
>>> <openmp-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.
>>>
>>> Chris has said it is because he thinks we'll never change the "3”,
>>>
>>>
>>> Yes, that is one reason.
>>>
>>> but I don't understand why 3.10 is worse than 3.9 was in that respect.
>>>
>>>
>>> Because it breaks from the established pattern we have, and means that we
>>> never get to 4.
>>>
>>> I happen to agree that we'll never change the "3", but I don't think this
>>> makes 3.10 a particularly bad choice.
>>>
>>>
>>> If you agree that we’ll never change the 3, then you are staying that you
>>> believe it is ok for the version number to be meaningless.  In that case, I
>>> can’t see why you’d object to a policy change.
>>>
>>> I believe that the version number is important.  Which is why I care so much
>>> about it :-)
>>>
>>> I think/hope we can agree that “Bitcode compatibility” is an obsolete notion
>>> to encode into the version number - from a historical perspective, we only
>>> used that as rationale because it happened to align well for the 1.9 to 2.0
>>> conversion and then used it as an excuse to shed some legacy in the 3.0
>>> timeframe.
>>>
>>> Given that, and given that we have a time based release, we should either
>>> leave the versioning alone (3.9/4.0/4.1) or switch to a semantic versioning
>>> model 3.9/4.0/5.0/6.0 or 3.9/40/41/42).
>>
>> Since there seems to be some kind of rough consensus forming around
>> the idea of moving towards a model with x.y version numbers where we
>> increment x every six months and y for the "dot" releases in between,
>> let's take it to a code review:
>>
>> http://reviews.llvm.org/D21821
>>
>> What angles am I missing? I'm sure this can break the world in
>> interesting ways. (It looks like Clang's cmake config is already set
>> up for this though, by checking CLANG_HAS_VERSION_PATCHLEVEL).
>
> For one thing, I can't find the patch on the mailing list ;).  I'm guessing
> you missed adding llvm-commits as a subscriber?

Good point :-) Added it now.