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

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>

On Sun, Jun 26, 2016 at 1:20 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:
> 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.
>
I am not sure what the confusion is actually. We can apply the following
test to see if the versioning scheme is simple/non-confusing or not: 1) for
release managers: given the current version, what is the next version going
to be? If it is predictable and not requiring lots of effort like this to
debate, then it is a good scheme (IMO); 2) for compiler/tool users: given
the current version, can I easily find out what the previous version is?
what is the version N releases ahead? If it requires googling, then it is
not a good scheme.

David


>
>>
>> *) 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/2c289d5a/attachment.html>

On Sun, Jun 26, 2016 at 1:20 PM, Chandler Carruth via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> 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.
We can't remove the '.' completely though, as we need it for
Tom's
stable releases.

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.

Thanks,
Hans

>> 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
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

Stable release can use a different numbering space -- a,b,c,d.     4.1a
means the first patch release of 4.1 release, etc.

David

On Mon, Jun 27, 2016 at 8:26 AM, Hans Wennborg <hans at chromium.org>
wrote:
> On Sun, Jun 26, 2016 at 1:20 PM, Chandler Carruth via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > 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.
>
> We can't remove the '.' completely though, as we need it for
Tom's
> stable releases.
>
> 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.
>
> Thanks,
> Hans
>
>
> >> 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
> >
> >
> > _______________________________________________
> > 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/20160627/67c2b4f6/attachment.html>

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

-Chris