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

On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev <
lldb-dev at lists.llvm.org> wrote:
> ----- Original Message -----
> > From: "Hans Wennborg via cfe-dev" <cfe-dev at
lists.llvm.org>
> > To: "llvm-dev" <llvm-dev at lists.llvm.org>,
"cfe-dev" <
> cfe-dev at lists.llvm.org>, "LLDB Dev" <lldb-dev at
lists.llvm.org>,
> > "openmp-dev (openmp-dev at lists.llvm.org)" <openmp-dev
at lists.llvm.org>
> > Cc: "r jordans" <r.jordans at tue.nl>, "Paul
Robinson" <
> Paul_Robinson at playstation.sony.com>
> > Sent: Monday, June 13, 2016 6:54:19 PM
> > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9 Release]
> Release plan and call for testers)
> >
> > 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.
> >
> > Brain-dump so far:
> >
> > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0
> > comes after 3.9.
> >
> > - There are special bitcode stability rules [1] concerning major
> > version bumps. 2.0 and 3.0 had major IR changes, but since there
> > aren't any this time, we should go to 3.10.
> >
> > - The bitcode stability rules allow for breakage with major versions,
> > but it doesn't require it, so 4.0 is fine.
> >
> > - But maybe we want to save 4.0 for when we do have a significant IR
> > change?
>
> I think that this is the right approach, and we happen to have a natural
> forcing function here: opaque pointer types. I think we should increment
> the major version number when opaque pointer types are here, as it will be
> a major breaking change, and then we'll have a version 4.0. Until then,
> unless something else breaking comes up, 3.10 sounds fine to me.
>
+1, complete agreement.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160614/9ef9b48e/attachment.html>

>> I think that this is the right approach, and we happen to have a
natural
>> forcing function here: opaque pointer types. I think we should
increment the
>> major version number when opaque pointer types are here, as it will be
a
>> major breaking change, and then we'll have a version 4.0. Until
then, unless
>> something else breaking comes up, 3.10 sounds fine to me.
> +1, complete agreement.
Agree


-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University

On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
>
>> ----- Original Message -----
>> > From: "Hans Wennborg via cfe-dev" <cfe-dev at
lists.llvm.org>
>> > To: "llvm-dev" <llvm-dev at lists.llvm.org>,
"cfe-dev" <
>> cfe-dev at lists.llvm.org>, "LLDB Dev" <lldb-dev at
lists.llvm.org>,
>> > "openmp-dev (openmp-dev at lists.llvm.org)"
<openmp-dev at lists.llvm.org>
>> > Cc: "r jordans" <r.jordans at tue.nl>, "Paul
Robinson" <
>> Paul_Robinson at playstation.sony.com>
>> > Sent: Monday, June 13, 2016 6:54:19 PM
>> > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9
Release]
>> Release plan and call for testers)
>> >
>> > 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.
>> >
>> > Brain-dump so far:
>> >
>> > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0
>> > comes after 3.9.
>> >
>> > - There are special bitcode stability rules [1] concerning major
>> > version bumps. 2.0 and 3.0 had major IR changes, but since there
>> > aren't any this time, we should go to 3.10.
>> >
>> > - The bitcode stability rules allow for breakage with major
versions,
>> > but it doesn't require it, so 4.0 is fine.
>> >
>> > - But maybe we want to save 4.0 for when we do have a significant
IR
>> > change?
>>
>> I think that this is the right approach, and we happen to have a
natural
>> forcing function here: opaque pointer types. I think we should
increment
>> the major version number when opaque pointer types are here, as it will
be
>> a major breaking change, and then we'll have a version 4.0. Until
then,
>> unless something else breaking comes up, 3.10 sounds fine to me.
>>
>
> +1, complete agreement.
>
While I'm not sure opaque pointer types are going to increment versions
I'm
also in agreement that 3.10 is the right way to go.

-eric

> _______________________________________________
> 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/20160614/6974bfb3/attachment.html>

On Tue, Jun 14, 2016 at 11:51 AM, Eric Christopher via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
>
>
> On Tue, Jun 14, 2016 at 12:43 AM Chandler Carruth via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev <
>> lldb-dev at lists.llvm.org> wrote:
>>
>>> ----- Original Message -----
>>> > From: "Hans Wennborg via cfe-dev" <cfe-dev at
lists.llvm.org>
>>> > To: "llvm-dev" <llvm-dev at lists.llvm.org>,
"cfe-dev" <
>>> cfe-dev at lists.llvm.org>, "LLDB Dev" <lldb-dev at
lists.llvm.org>,
>>> > "openmp-dev (openmp-dev at lists.llvm.org)"
<openmp-dev at lists.llvm.org>
>>> > Cc: "r jordans" <r.jordans at tue.nl>,
"Paul Robinson" <
>>> Paul_Robinson at playstation.sony.com>
>>> > Sent: Monday, June 13, 2016 6:54:19 PM
>>> > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9
Release]
>>> Release plan and call for testers)
>>> >
>>> > 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.
>>> >
>>> > Brain-dump so far:
>>> >
>>> > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally,
4.0
>>> > comes after 3.9.
>>> >
>>> > - There are special bitcode stability rules [1] concerning
major
>>> > version bumps. 2.0 and 3.0 had major IR changes, but since
there
>>> > aren't any this time, we should go to 3.10.
>>> >
>>> > - The bitcode stability rules allow for breakage with major
versions,
>>> > but it doesn't require it, so 4.0 is fine.
>>> >
>>> > - But maybe we want to save 4.0 for when we do have a
significant IR
>>> > change?
>>>
>>> I think that this is the right approach, and we happen to have a
natural
>>> forcing function here: opaque pointer types. I think we should
increment
>>> the major version number when opaque pointer types are here, as it
will be
>>> a major breaking change, and then we'll have a version 4.0.
Until then,
>>> unless something else breaking comes up, 3.10 sounds fine to me.
>>>
>>
>> +1, complete agreement.
>>
>
> While I'm not sure opaque pointer types are going to increment versions
> I'm also in agreement that 3.10 is the right way to go.
>
+1

-- Sean Silva

>
> -eric
>
>
>> _______________________________________________
>> 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/20160614/f2add77c/attachment.html>