llvm dev - Jun 2016 - [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).

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

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

On Jun 14, 2016, at 1:32 AM, Richard Smith via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
> 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.
I completely agree with Richard here.  “Breaking of IR compatibility” was an
interesting metric for older and less mature versions of LLVM.  We can solve the
same sort of challenge (the desire to eject old autoupgrade code) by having a
sliding window of versions supported (e.g. version 4.5 supports back to version
3.6).

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160618/6430f26e/attachment.html>

> On Jun 18, 2016, at 9:16 PM, Chris Lattner via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On Jun 14, 2016, at 1:32 AM, Richard Smith via cfe-dev <cfe-dev at
lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>> 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.
> 
> I completely agree with Richard here.  “Breaking of IR compatibility” was
an interesting metric for older and less mature versions of LLVM.  We can solve
the same sort of challenge (the desire to eject old autoupgrade code) by having
a sliding window of versions supported (e.g. version 4.5 supports back to
version 3.6).
Let me clarify.  What I’m trying to say is that:

a) LLVM has a time-based release cycle, not a schedule-based one.  As such, a
simple and predictable version number makes sense.
b) The LLVM project as a whole is a lot bigger than LLVM IR, even given its
centrality to the project in some ways.
c) I think that it makes sense to keep adding 0.1 to each major release going
forward well into the future.

On the topic of the pointer changes proposed, I really don’t think the community
is served by waiting for that.  The supposition seems to be that we’d land it
*without* upgrade support, but then bump the major version number to indicate
this.  If that’s the proposal, I think that doing such a thing would be
disastrous for the LLVM community as a whole: we need to have at least some
sliding window of support for older formats.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160618/8f324335/attachment.html>

Ø  We can solve the same sort of challenge (the desire to eject old autoupgrade
code) by having a sliding window of versions supported (e.g. version 4.5
supports back to version 3.6).

How easy/hard is it to identify the minor release associated with a particular
auto-upgrade feature?  My impression is that they aren't identified that way
in the source, that it would be an archeological dig each time to figure out
which bits could be removed.
--paulr

From: Chris Lattner [mailto:clattner at apple.com]
Sent: Saturday, June 18, 2016 9:16 PM
To: Richard Smith
Cc: Hal Finkel; llvm-dev; openmp-dev (openmp-dev at lists.llvm.org); LLDB Dev; r
jordans; cfe-dev; Robinson, Paul
Subject: Re: [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release
plan and call for testers)

On Jun 14, 2016, at 1:32 AM, Richard Smith via cfe-dev <cfe-dev at
lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> wrote:
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.

I completely agree with Richard here.  “Breaking of IR compatibility” was an
interesting metric for older and less mature versions of LLVM.  We can solve the
same sort of challenge (the desire to eject old autoupgrade code) by having a
sliding window of versions supported (e.g. version 4.5 supports back to version
3.6).

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/00ba0b45/attachment.html>