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

> On Jun 19, 2016, at 4:25 AM, via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
<snip>
> 
>>>> 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.

Now you’re making the versions sound like floating point numbers :-).  Just to
be clear, you are proposing we use 3.10/3.11/etc. rather than 4.0/4.1/etc.?

If so, I agree with that for a couple of reasons.  First, as several people
said, version numbers should not be driven primarily by IR changes: the LLVM
project is a lot more than the IR, even though the IR is a fundamental
component.  Our releases are time-based and the predictability of that has
worked pretty well.

A second reason is that major version numbers also have a useful 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 turn out to be the next major change -- but
regardless of what the change is, I think there is some value in reserving major
version increments (like 3.x.y to 4.0) when major changes happen.

--Vikram

> 
>> 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
> To be clear, that's not at all what I was saying. The plan has always
been to have upgrade support. My thought was that once the pointer changes land,
it will mean major changes in how many frontends and IR transformations use the
API. A lot of out-of-tree frontends and passes support multiple versions of
LLVM, and use ifdefs to work around relevant API changes. For the most part,
this works reasonably, and the changes necessary between versions are not often
large (perhaps especially because we have time-based releases). I suspect,
however, that the amount of code changes necessary to adapt for the pointer
changes will be much larger, and so calling that a new major version seems
fitting.
> 
> -Hal 

-—Vikram

// Vikram S. Adve
// Professor, Department of Computer Science
// University of Illinois at Urbana-Champaign
// vadve at illinois.edu
// http://llvm.org

On Jun 19, 2016, at 10:21 AM, Adve, Vikram Sadanand via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>> 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.
> 
> 
> Now you’re making the versions sound like floating point numbers :-).  Just
to be clear, you are proposing we use 3.10/3.11/etc. rather than 4.0/4.1/etc.?
No, I’m suggesting that we continue the progression we’ve had from the start and
proceed from 3.8 to 3.9 to 4.0 to 4.1.
> If so, I agree with that for a couple of reasons.  First, as several people
said, version numbers should not be driven primarily by IR changes: the LLVM
project is a lot more than the IR, even though the IR is a fundamental
component.  Our releases are time-based and the predictability of that has
worked pretty well.
> 
> A second reason is that major version numbers also have a useful
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 turn out to be the next major
change -- but regardless of what the change is, I think there is some value in
reserving major version increments (like 3.x.y to 4.0) when major changes
happen.
These seem like contradictory points: on the one hand you’re observing that we
have an inherently schedule driven process, but are also saying that major
version numbers are important to signify “major” changes.  Given the scope of
LLVM, I suspect we’ll never have a “major” change that lines up across all of
the sub-projects, so this doesn’t seem like something we should bank on.

I don’t think that there is really a problem to solve here, but if we were
sufficiently motivated to “solve” this problem, then the answer is obvious:
instead of 4.0, we should just go to 40, and add one for every release after
that.

-Chris

> On Jun 20, 2016, at 11:56 PM, Chris Lattner <clattner at apple.com>
wrote:
> 
> On Jun 19, 2016, at 10:21 AM, Adve, Vikram Sadanand via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>>>> 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.
>> 
>> 
>> Now you’re making the versions sound like floating point numbers :-). 
Just to be clear, you are proposing we use 3.10/3.11/etc. rather than
4.0/4.1/etc.?
> 
> No, I’m suggesting that we continue the progression we’ve had from the
start and proceed from 3.8 to 3.9 to 4.0 to 4.1.
> 
>> If so, I agree with that for a couple of reasons.  First, as several
people said, version numbers should not be driven primarily by IR changes: the
LLVM project is a lot more than the IR, even though the IR is a fundamental
component.  Our releases are time-based and the predictability of that has
worked pretty well.
>> 
>> A second reason is that major version numbers also have a useful
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 turn out to be the next major
change -- but regardless of what the change is, I think there is some value in
reserving major version increments (like 3.x.y to 4.0) when major changes
happen.
> 
> These seem like contradictory points: on the one hand you’re observing that
we have an inherently schedule driven process, but are also saying that major
version numbers are important to signify “major” changes.

Not contradictory at all.  The schedule is for *when* we release new versions;
it is unrelated to any numbering scheme.  The major vs. minor version numbers
capture something about how important a release is.  I don’t really have a
preference one way or another, but I do think people are missing a basic point
about the numbering.

> Given the scope of LLVM, I suspect we’ll never have a “major” change that
lines up across all of the sub-projects, so this doesn’t seem like something we
should bank on.
Agreed, but you could introduce a new major version when there is something
really major in any major part of the ecosystem.  E.g., making Clang the primary
C/C++ compiler instead of llvm-gcc could have qualified.
> 
> I don’t think that there is really a problem to solve here, but if we were
sufficiently motivated to “solve” this problem, then the answer is obvious:
instead of 4.0, we should just go to 40, and add one for every release after
that.
Sounds like a stretch to me, but whatever!
> 
> -Chris
> 
—Vikram

On Tue, Jun 21, 2016 at 7:56 AM Chris Lattner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Jun 19, 2016, at 10:21 AM, Adve, Vikram Sadanand via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >>> 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.
> >
> >
> > Now you’re making the versions sound like floating point numbers :-).
> Just to be clear, you are proposing we use 3.10/3.11/etc. rather than
> 4.0/4.1/etc.?
>
> No, I’m suggesting that we continue the progression we’ve had from the
> start and proceed from 3.8 to 3.9 to 4.0 to 4.1.
>
I'm sympathetic to the idea that we should move to a sliding window for IR
compatibility if that's useful.

However, I think it is a really big mistake to *have* a major version and
just increment it arbitrarily without any associated "major" change.
Lacking us explaining what we consider to be a major release, people will
make assumptions that will inevitably lead to missed expectations.

If we want to have a major/minor split, I think we need to have *some*
guidance for what will constitute a major jump. I don't think it needs to
necessarily be formulaic (like bitcode compatibility), it could be when a
feature happens to be ready and happens to be decided by the community to
be "big enough" we flip the major version and announce that feature
happened to be ready. But we shouldn't just go from 3.9 to 4.0 because of
some decimal correspondence. Too many people will assume it had
significance and become disappointed.

If we *don't* want a major/minor split, then I believe Richard's
suggestion
is the correct one: just have integers to mark the temporal releases, and
dot releases for updates to that release branch.

I personally don't have strong feelings about whether we should or
shouldn't have a major/minor split. I see arguments on both sides. But I
really do not want us to have a *meaningless* split.

-Chandler

>
> > If so, I agree with that for a couple of reasons.  First, as several
> people said, version numbers should not be driven primarily by IR changes:
> the LLVM project is a lot more than the IR, even though the IR is a
> fundamental component.  Our releases are time-based and the predictability
> of that has worked pretty well.
> >
> > A second reason is that major version numbers also have a useful
> 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 turn out to be
> the next major change -- but regardless of what the change is, I think
> there is some value in reserving major version increments (like 3.x.y to
> 4.0) when major changes happen.
>
> These seem like contradictory points: on the one hand you’re observing
> that we have an inherently schedule driven process, but are also saying
> that major version numbers are important to signify “major” changes.  Given
> the scope of LLVM, I suspect we’ll never have a “major” change that lines
> up across all of the sub-projects, so this doesn’t seem like something we
> should bank on.
>
> I don’t think that there is really a problem to solve here, but if we were
> sufficiently motivated to “solve” this problem, then the answer is obvious:
> instead of 4.0, we should just go to 40, and add one for every release
> after that.
>
> -Chris
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/ca75b890/attachment.html>