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

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”?

-Chris

On Jun 27, 2016, at 9:57 PM, Chris Lattner via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I continue to think that 3.10 is the least defensible option out there.  
I agree, given that there isn’t a concurrent agreement that we want to define
and conform to a semantic versioning scheme — and that agreement not only hasn’t
happened but seems quite unlikely.
> 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.
Yes, that does seem likely.
> I still don’t understand what “confusion” could be caused by going from 3.9
to 4.0.
I believe it is rooted in some folks expectation that the versions follow the
semantic versioning paradigm.    A numbering scheme that more directly indicated
“time-based”, and that had less of a chance of being interpreted as conveying
semantic content would indeed be less “confusing”.
> Could someone please elaborate on what the problem is that needs solving?  
I think the real point, mostly unspoken, is this expectation for semantic
versioning.   Since that isn’t directly being discussed, I also don’t see a
problem that needs solving.

Jim Rowan
jmr at codeaurora.org
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation

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

> -----Original Message-----
> From: hwennborg at google.com [mailto:hwennborg at google.com] On Behalf Of
Hans
> Wennborg
> On Mon, Jun 27, 2016 at 7:57 PM, Chris Lattner <clattner at
apple.com> wrote:
> > 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.
Somebody proposed a time-based-version bitcode compatibility policy.
IMHO the easiest to remember would be "X.Y supports back to (X-1).Y"
but opinions vary (e.g. 3 years, where my idea would mean 5 years) and
nobody has tried to nail one down.

Of course actually removing an auto-upgrade feature means having to do
the archaeology to figure out when each piece was introduced, and then
how to disentangle it cleanly.  I'm not aware that these things are
identified by version, other than by researching the commit history.
With the old scheme, you'd just rip it all out at 4.1 without having
to worry about when each piece was introduced.  With the time-based
scheme there's a higher barrier to removing the old code.
--paulr
> 
> But if you really insist on 4.0 rather than 3.10, I will of course honour
> that.
> 
> Cheers,
> Hans

> 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.
It is tied in saying we *can* drop compatibility, not that we will. If
we still support loading 3.0 bitcode when 4.1 ships we just have to
document that. It just given us the flexibility to drop it in 4.2 if
we want.

Cheers,
Rafael

> On Jun 28, 2016, at 8:40 AM, Hans Wennborg <hans at chromium.org>
wrote:
> 
>> 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.
If that is the confusion, then I suggest that we just document (in the release
notes) what the supported compatibility range is for any release.  That makes it
completely unambiguous, and means that we don’t have to make an arbitrary policy
up front (exactly N years of support!), we can drive it based on the
cost/benefit involved with making a specific change.

Besides, people “expecting” 4.0 to break compatibility will likely ask about it,
and be pleasantly surprised :-).  I don’t think that the association of major
number to bitcode compatibility is actually well known outside the core group of
folks that hang out on llvm-dev anyway.

I think that there is a reasonable argument to be made for switching to a
semantic versioning model.  Instead of 3.9, 4.0, 4.1 we would switch to 4.0,
5.0, 6.0 and then “4.1” would be a patch release.  It appears that jumping to 40
just freaks too many people out.

-Chris