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

[Hans Wennborg via cfe-dev]

On Mon, Jun 27, 2016 at 7:57 PM, Chris Lattner <clattner at apple.com> wrote:
> On Jun 27, 2016, at 4:57 PM, Hans Wennborg <hans at chromium.org> wrote:
>>> Eh, if we're switching to a completely unrelated versioning scheme, it
>>> doesn't seem completely unreasonable.
>>>
>>> We could also count how many time-based releases we have had and use that...
>>>
>>> :: shrug ::
>>>
>>> I think counting from 4 or counting from 40 are all fine ways to number
>>> releases.
>>
>>
>> This is what I arrived at after my weekend of thinking about version numbers:
>>
>> While there's been many good arguments for doing something different
>> and revising our versioning scheme, I really just want to bump the
>> number with the least amount of work possible.
>>
>> When we branch for 3.9, my plan is to bump trunk to 3.10, and then
>> focus my attention on getting 3.9 into a good state and shipping it.
>>
>> After the branch, if someone wants to promote trunk to 4.0 because of
>> a feature, or because the 3-series is "done", go ahead. If someone
>> wants to spearhead getting us onto a scheme where we increment major
>> for each release, that's fine too, but I'm not going to drive it.
>>
>> Thanks everyone for participating in the discussion. Hopefully this
>> result is not too disappointing.
>
> I continue to think that 3.10 is the least defensible option out there.  We have a time based release process with no mechanism or attempt to align behind “big” releases that could bring is to a 4.x number.  You might as well call the release “10” at this point, since the "3.” will become archaic legacy that we can’t shed.
>
> Trust me, I’ve seen this happen several times in the past in multiple different products (both open source and proprietary), and have had success leading one to a more predictable release number pattern like I’m advocating for.  This is a problem that we are simply walking into by naming it 3.10, there is no reason to do that.
>
> I still don’t understand what “confusion” could be caused by going from 3.9 to 4.0.  Could someone please elaborate on what the problem is that needs solving?  If it is that people don’t understand what is major about the release, I would say “who cares”?

I think the main issue (besides users asking what's the big change in
4.0, which I agree is not a big problem) is that the bitcode
compatibility policy is tied to the major version number.

But if you really insist on 4.0 rather than 3.10, I will of course honour that.

Cheers,
Hans