[llvm-dev] (no subject)

Tue Jun 14 19:51:26 PDT 2016

> Date: Tue, 14 Jun 2016 07:43:17 +0000
> From: Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org>
> To: Hal Finkel <hfinkel at anl.gov>, Hans Wennborg <hans at chromium.org>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>, "openmp-dev
>    \(openmp-dev at lists.llvm.org\)" <openmp-dev at lists.llvm.org>, LLDB Dev
>    <lldb-dev at lists.llvm.org>, cfe-dev <cfe-dev at lists.llvm.org>, Paul
>    Robinson <Paul_Robinson at playstation.sony.com>
> Subject: Re: [llvm-dev] [lldb-dev] [cfe-dev] What version comes after
>    3.9? (Was: [3.9 Release] Release plan and call for testers)
> Message-ID:
>    <CAGCO0Kiuxk_qnoXknFzHh3b71WLanux9FFnvPEFOX8emEJ0uFQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> 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.

I agree with the suggestion but for a different reason -- see below.

> +1, complete agreement.

> Date: Tue, 14 Jun 2016 01:32:30 -0700
> From: Richard Smith via llvm-dev <llvm-dev at lists.llvm.org>
> To: Hal Finkel <hfinkel at anl.gov>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>, "openmp-dev
>    \(openmp-dev at lists.llvm.org\)" <openmp-dev at lists.llvm.org>, LLDB Dev
>    <lldb-dev at lists.llvm.org>, cfe-dev <cfe-dev at lists.llvm.org>, Paul
>    Robinson <Paul_Robinson at playstation.sony.com>
> Subject: Re: [llvm-dev] [cfe-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 cfe-dev <
> cfe-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.
> 
> We're talking about version numbers for the entire LLVM project here, which
> encompasses a lot more than LLVM IR, and for many parts of which LLVM IR is
> utterly irrelevant. I'm not convinced that tying version numbers to
> backwards-incompatible changes to IR is reasonable any more, and it doesn't
> seem hard to explicitly document the oldest version with which we are
> compatible (in fact, we need to do that regardless, whether we say it's
> "the same major version" or "everything since 3.0" or whatever else).
> 

I agree that the LLVM system is a lot more than the IR, and version numbers should not be driven primarily by IR changes.  Our releases have indeed been time-based recently, and the predictability has worked pretty well.

However, major version numbers also have a communication value: signifying a major step forward in the system along some dimension.  It just so happens that these major changes have been IR changes in the past -- and perhaps opaque pointer types will be the next major change -- but regardless of what the change is, I do think there is some value in reserving major version increments (like 3.xyz to 4.xyz) for major changes.  3.9 is not a fraction -- if it was, we would not have 3.7.1 etc. -- so there is really no reason not to increment 9 to 10 to 11 and so on until we reach a point of major change, whatever that may be.

--Vikram

> Given that our releases are time-based rather than feature-based, I don't
> see a distinct major / minor version being anything other than arbitrary,
> so I'd suggest we take 4.0 as our next release, 4.1 as the first patch
> release on that, 5.0 as the next release after that, and so on.
> 
> -Hal
>> 
>>> 
>>> - We've never had an x.10 version before; maybe that would be
>>> confusing? Perhaps it's simply time to move on (like Linux 2.6.39 ->
>>> 3.0 and 3.19 -> 4.0).
>>> 
>>> - Since we do time-based rather than feature-based releases, the
>>> major
>>> version number shouldn't mean anything special anyway (e.g. big IR
>>> changes or not), so 4.0?
>>> 
>>> - Everyone knows that after 9 comes 10, so 3.10 it is. The version is
>>> a tuple after all.
>>> 
>>> - Let's go for 4.0 now, and 5.0 after that. Then the "dot"-releases
>>> in
>>> between would correspond to minor version bumps, which would make
>>> sense (and catch up with GCC!).
>>> 
>>> - It's just a number, no big deal; flip a coin or something.
>>> 
>>> What do you think?
>>> 
>>> - Hans
>>> 
>>> 
>>> [1].
>>> http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> 
>> --
>> Hal Finkel
>> Assistant Computational Scientist
>> Leadership Computing Facility
>> Argonne National Laboratory
>> _______________________________________________
>> 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/86cd2e05/attachment-0001.html>