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 Mon, Jun 27, 2016 at 3:38 PM Hans Wennborg via lldb-dev <
lldb-dev at lists.llvm.org> wrote:
> On Mon, Jun 27, 2016 at 3:29 PM, Chris Lattner <clattner at
apple.com> wrote:
> > On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >> That's what concerns me about going to the scheme Richard and
Rafael
> >> suggested, of bumping the major version each time: we'd
release 4.0,
> >> and would Tom's dot-release then be 4.1? That would be
confusing to
> >> those who are used to our current scheme. Chris suggested going
> >> straight to 40 to avoid this, but that also seems a bit extreme.
> >
> > Extreme how?  What do you mean by “extreme"?
>
> Sorry, that might have been a poor choice of wording.
>
> I just meant that change seems to have a much greater magnitude than
> the other proposals. I realize that's sort of the point, to make the
> change clear to users, but instinctively it feels wrong -- like
> cheating by skipping 36 versions :-)
>
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.

>
> Thanks,
> Hans
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160627/e1fdc013/attachment.html>

On Mon, Jun 27, 2016 at 3:40 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:
> On Mon, Jun 27, 2016 at 3:38 PM Hans Wennborg via lldb-dev
> <lldb-dev at lists.llvm.org> wrote:
>>
>> On Mon, Jun 27, 2016 at 3:29 PM, Chris Lattner <clattner at
apple.com> wrote:
>> > On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev
>> > <llvm-dev at lists.llvm.org> wrote:
>> >> That's what concerns me about going to the scheme Richard
and Rafael
>> >> suggested, of bumping the major version each time: we'd
release 4.0,
>> >> and would Tom's dot-release then be 4.1? That would be
confusing to
>> >> those who are used to our current scheme. Chris suggested
going
>> >> straight to 40 to avoid this, but that also seems a bit
extreme.
>> >
>> > Extreme how?  What do you mean by “extreme"?
>>
>> Sorry, that might have been a poor choice of wording.
>>
>> I just meant that change seems to have a much greater magnitude than
>> the other proposals. I realize that's sort of the point, to make
the
>> change clear to users, but instinctively it feels wrong -- like
>> cheating by skipping 36 versions :-)
>
>
> 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.

Cheers,
Hans

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