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

I also support Chris's position of 4.0, 4.1 etc. I don't think
"majorness"
is that important, and we can sort out the bit code compatibility story
some other way.

Sent from phone
On Jun 24, 2016 4:42 PM, "Hans Wennborg via llvm-dev" <
llvm-dev at lists.llvm.org> wrote:
> On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg <hans at chromium.org>
wrote:
> > Breaking this out into a separate thread since it's kind of a
separate
> > issue, and to make sure people see it.
> >
> > If you have opinions on this, please chime in. I'd like to collect
as
> > many arguments here as possible to make a good decision. The main
> > contestants are 4.0 and 3.10, and I've seen folks being equally
> > surprised by both.
>
> Thanks everyone for chiming in.
>
> Please correct me if I misrepresent your opinion here, but I need to
> try and summarize this thread for my own sanity:
>
> The thread started out with lots of support for 3.10, the reasoning
> being roughly that we shouldn't bump the major version number unless
> we want to signify major change (Mehdi, Hal, Blaikie, Saleem,
> Chandler, Anton, Eric, Aaron, Sean, Vikram).
>
> Richard suggested that since we do time-based rather than
> feature-based releases, the distinction between a release with or
> without major changes is arbitrary, and we should move to a scheme
> where we update the major version number on each release (4.0, 5.0,
> etc.) with minor releases in between (4.1, 5.1, ..).
>
> Chris advocated for "keep adding 0.1 to each major release" (in
the
> decimal sense), i.e. 3.9, 4.0, 4.1, etc. I haven't seen anyone else
> suggest this. "I do not think it is reasonable at all to go to
'3.10'
> after '3.9', because we will never get to '4.0'."
>
> Chris then expressed support for alternatively just incrementing the
> major version each time, as Richard suggested, but starting at 40.
>
> Rafael expressed support for the above, but starting at 4.0: "It is
> simply not worth the time to try to figure out what is 'major' in a
> project with so many different uses."
>
> Chandler said he didn't like Chris's "keep adding 0.1 to each
major
> release" scheme: "we shouldn't just go from 3.9 to 4.0
because of some
> decimal correspondence", and said he was open to either going to 3.10
> with the current major/minor split, or if we don't want that, use
> Richard's suggestion.
>
> Michael pointed out that if we do change the numbering scheme,
> changing the binary compatibility guarantee to something time-based
> isn't equivalent to what we currently have.
>
>
>
> So, it seems we're at an impasse with several folks in favour of 3.10,
> Chris speaking out strongly against it, and Richard's option which has
> some traction and which no one's disagreed with so far, but which
> would be a bigger change.
>
> I'll have a think about this over the weekend.
>
> Cheers,
> Hans
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160626/4e4ccd5f/attachment-0001.html>

I also believe this is the simplest versioning scheme*. It eliminates all
future debates on this topic (e.g, when to bump major version etc) and
solves the problem once and for all --  which is another plus :)

*) similar suggestions a) start from 4, increase by 1; b) start from 40,
increase by 1.   Date based scheme is also a variant of it.

David


On Sun, Jun 26, 2016 at 7:21 AM, Reid Kleckner via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> I also support Chris's position of 4.0, 4.1 etc. I don't think
"majorness"
> is that important, and we can sort out the bit code compatibility story
> some other way.
>
> Sent from phone
> On Jun 24, 2016 4:42 PM, "Hans Wennborg via llvm-dev" <
> llvm-dev at lists.llvm.org> wrote:
>
>> On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg <hans at
chromium.org> wrote:
>> > Breaking this out into a separate thread since it's kind of a
separate
>> > issue, and to make sure people see it.
>> >
>> > If you have opinions on this, please chime in. I'd like to
collect as
>> > many arguments here as possible to make a good decision. The main
>> > contestants are 4.0 and 3.10, and I've seen folks being
equally
>> > surprised by both.
>>
>> Thanks everyone for chiming in.
>>
>> Please correct me if I misrepresent your opinion here, but I need to
>> try and summarize this thread for my own sanity:
>>
>> The thread started out with lots of support for 3.10, the reasoning
>> being roughly that we shouldn't bump the major version number
unless
>> we want to signify major change (Mehdi, Hal, Blaikie, Saleem,
>> Chandler, Anton, Eric, Aaron, Sean, Vikram).
>>
>> Richard suggested that since we do time-based rather than
>> feature-based releases, the distinction between a release with or
>> without major changes is arbitrary, and we should move to a scheme
>> where we update the major version number on each release (4.0, 5.0,
>> etc.) with minor releases in between (4.1, 5.1, ..).
>>
>> Chris advocated for "keep adding 0.1 to each major release"
(in the
>> decimal sense), i.e. 3.9, 4.0, 4.1, etc. I haven't seen anyone else
>> suggest this. "I do not think it is reasonable at all to go to
'3.10'
>> after '3.9', because we will never get to '4.0'."
>>
>> Chris then expressed support for alternatively just incrementing the
>> major version each time, as Richard suggested, but starting at 40.
>>
>> Rafael expressed support for the above, but starting at 4.0: "It
is
>> simply not worth the time to try to figure out what is 'major'
in a
>> project with so many different uses."
>>
>> Chandler said he didn't like Chris's "keep adding 0.1 to
each major
>> release" scheme: "we shouldn't just go from 3.9 to 4.0
because of some
>> decimal correspondence", and said he was open to either going to
3.10
>> with the current major/minor split, or if we don't want that, use
>> Richard's suggestion.
>>
>> Michael pointed out that if we do change the numbering scheme,
>> changing the binary compatibility guarantee to something time-based
>> isn't equivalent to what we currently have.
>>
>>
>>
>> So, it seems we're at an impasse with several folks in favour of
3.10,
>> Chris speaking out strongly against it, and Richard's option which
has
>> some traction and which no one's disagreed with so far, but which
>> would be a bigger change.
>>
>> I'll have a think about this over the weekend.
>>
>> Cheers,
>> Hans
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160626/396b0ba6/attachment.html>

On Sun, Jun 26, 2016 at 10:01 AM Xinliang David Li via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> I also believe this is the simplest versioning scheme*. It eliminates all
> future debates on this topic (e.g, when to bump major version etc) and
> solves the problem once and for all --  which is another plus :)
>
Except that we'll have to keep dealing with people who are confused why we
have two version numbers but they don't mean anything. That's why I
think
if we don't want major/minor going forward, we should remove the '.'
regardless of what number we pick.

>
> *) similar suggestions a) start from 4, increase by 1; b) start from 40,
> increase by 1.   Date based scheme is also a variant of it.
>
> David
>
>
> On Sun, Jun 26, 2016 at 7:21 AM, Reid Kleckner via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> I also support Chris's position of 4.0, 4.1 etc. I don't think
>> "majorness" is that important, and we can sort out the bit
code
>> compatibility story some other way.
>>
>> Sent from phone
>> On Jun 24, 2016 4:42 PM, "Hans Wennborg via llvm-dev" <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg <hans at
chromium.org>
>>> wrote:
>>> > Breaking this out into a separate thread since it's kind
of a separate
>>> > issue, and to make sure people see it.
>>> >
>>> > If you have opinions on this, please chime in. I'd like to
collect as
>>> > many arguments here as possible to make a good decision. The
main
>>> > contestants are 4.0 and 3.10, and I've seen folks being
equally
>>> > surprised by both.
>>>
>>> Thanks everyone for chiming in.
>>>
>>> Please correct me if I misrepresent your opinion here, but I need
to
>>> try and summarize this thread for my own sanity:
>>>
>>> The thread started out with lots of support for 3.10, the reasoning
>>> being roughly that we shouldn't bump the major version number
unless
>>> we want to signify major change (Mehdi, Hal, Blaikie, Saleem,
>>> Chandler, Anton, Eric, Aaron, Sean, Vikram).
>>>
>>> Richard suggested that since we do time-based rather than
>>> feature-based releases, the distinction between a release with or
>>> without major changes is arbitrary, and we should move to a scheme
>>> where we update the major version number on each release (4.0, 5.0,
>>> etc.) with minor releases in between (4.1, 5.1, ..).
>>>
>>> Chris advocated for "keep adding 0.1 to each major
release" (in the
>>> decimal sense), i.e. 3.9, 4.0, 4.1, etc. I haven't seen anyone
else
>>> suggest this. "I do not think it is reasonable at all to go to
'3.10'
>>> after '3.9', because we will never get to
'4.0'."
>>>
>>> Chris then expressed support for alternatively just incrementing
the
>>> major version each time, as Richard suggested, but starting at 40.
>>>
>>> Rafael expressed support for the above, but starting at 4.0:
"It is
>>> simply not worth the time to try to figure out what is
'major' in a
>>> project with so many different uses."
>>>
>>> Chandler said he didn't like Chris's "keep adding 0.1
to each major
>>> release" scheme: "we shouldn't just go from 3.9 to
4.0 because of some
>>> decimal correspondence", and said he was open to either going
to 3.10
>>> with the current major/minor split, or if we don't want that,
use
>>> Richard's suggestion.
>>>
>>> Michael pointed out that if we do change the numbering scheme,
>>> changing the binary compatibility guarantee to something time-based
>>> isn't equivalent to what we currently have.
>>>
>>>
>>>
>>> So, it seems we're at an impasse with several folks in favour
of 3.10,
>>> Chris speaking out strongly against it, and Richard's option
which has
>>> some traction and which no one's disagreed with so far, but
which
>>> would be a bigger change.
>>>
>>> I'll have a think about this over the weekend.
>>>
>>> Cheers,
>>> Hans
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160626/67734d6d/attachment.html>