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

Tue Jun 14 11:56:33 PDT 2016

On Tue, Jun 14, 2016 at 1:32 AM Richard Smith via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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).
>
> 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.
>

This seems oddly familiar.

So, one point is that LLVM's IR compatibility impacts more projects than
many other things do:
- Clang generates bitcode with '-flto' and cares about compatibility with
it.
- LLD imports bitcode for LTO and cares about compatibility with it.

Certainly, LLDB and libc++ are both ... substantially less impacted.

All that said, I'm not opposed to a dramatically simpler version numbering
scheme which just counts cycles provided we also establish some strategy
for marking the bitcode compatibility requirements.

But I also don't see it as an important change to make right now.
-Chandler

>  -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
>>
> _______________________________________________
> 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/lldb-dev/attachments/20160614/42487f56/attachment-0001.html>