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

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>

On 21 June 2016 at 07:38, Chandler Carruth via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> 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.
Precisely.

> 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.
That is how I feel too. But I think we need to take am informed
decision before July (ie. not continue the status quo).

Continuing (3.9 -> 4.0) is ok for some of us because we've seen 1.9 ->
2.0 and 2.9 -> 3.0, but it's not logical to most people out there,
including many in our community today.

Moving to an OSS-friendly can be very helpful, but not without a good
rule on what's "major". Not having a rule is also *not* a reason
to
continue the status quo.

I agree we don't need hard rules, and we can always argue for months
if the next one will be major or not, but I'd rather spend my time
elsewhere.

So, things that *could* influence a major change:

 * IR backwards compatibility: this one is obvious
 * Major internal refactoring: new pass manager, new selection dag,
(ex. when the MC layer was introduced)
 * Major new language support: c++17, openMP complete, etc.
 * DCE: When we delete whole back-ends (which obviously will be
backwards incompatible)

But in the end, it boils down to someone asking to up the number, and
a month long thread to agree or disagree, which is ok.

All in all, we need reasons to either side we pick.

cheers,
--renato

Pretty much exactly my thinking.

--Vikram
http://llvm.org


On Jun 21, 2016, at 1:38 AM, Chandler Carruth <chandlerc at
gmail.com<mailto:chandlerc at gmail.com>> wrote:


On Tue, Jun 21, 2016 at 7:56 AM Chris Lattner via llvm-dev <llvm-dev at
lists.llvm.org<mailto: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<mailto: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<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=CwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=b7uK7dJM4Fx7J_ehsuohEdD-6NdkoLyTwBFfHX-XKcc&m=0F342wvFQuyhZX9mX2qGe3FhhI7LEedDIDye0ptp-7w&s=aOlWUbHIrpP2knuQDt9tgn8hc_pwXrpFhzYiqcEAn6k&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/89832871/attachment.html>

> 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 like just having just integer. IMHO it is simply not worth the time
to try to figure out what is "major" in a project with so many
different uses.

So my vote goes to
* The bitcode compatibility promise is changed to use real time (at
least 5 years?) instead of revision numbers.
* The next release is 4.0.
* The next bugfix release is 4.1.
* After 6 months or so we release 5.0.

Cheers,
Rafael

Regardless of the numbering scheme debate, this part sounds somewhat
problematic to me.

The way I understand the current IR backward compatibility guarantee is
that the major version change is a notification strategy, not a commitment
to hold the IR stable for any given amount of time. That is, it's "If
we
need to change the IR, we'll bump the major version - but this may happen
on the next release". Not "The release schedule for major versions is
5
years, so if the current minor is 3.4, you have 3 more years of stable IR
to go".

This, I think, is a fairly good model. Promising IR stability N years into
the future is something we may easily come to regret.

On Tue, Jun 21, 2016 at 7:07 AM, Rafael Espíndola <llvm-dev at
lists.llvm.org>
wrote:
>
> * The bitcode compatibility promise is changed to use real time (at
> least 5 years?) instead of revision numbers.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/85a227d1/attachment.html>

On Jun 20, 2016, at 11:38 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:
> > 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.
I can see your point about our current naming scheme being confusable with
semantic versioning, but I don't think the risk is high and I don’t think
the problem is solving.  That is just MHO of course, and I totally respect and
understand that reasonable people would disagree with that.

What I care most about is aligning our versioning scheme with the practical
realities of how we manage the software, and giving our users some idea of what
we ship.  I do not think it is reasonable at all to go to “3.10” after “3.9”,
because we will never get to “4.0”.  The GCC community has been through this (as
one example) where they could never decide on when to bump to 5.0.  They
resolved the issue by going to the completely insane (again, IMVHO :-) version
scheme they have now.

The desire to align the version with how we release the product is what leads me
to think that the only rationale solution is to increment the version number
predictably with every release: we have a time based release.  I don’t care if
that is by adding 0.1 or by adding 1.


That is why I suggested that - if you believe that consistently adding 0.1 is
confusing - then the logical answer is to jump to "version 40” with the
post-3.9 major release and then add 1 on every other release after that.  Here
are the advantages I see:

 - This communicates clearly and obviously to users that we changed policy with
the version number scheme
 - Offers continuity with the prior approach (3.9 -> 40 is something that
people will be able to remember)
 - Aligns the new version number scheme with how the project is managed
 - Aligns the version numbers with the expectations of semantic versioning
(since every release of LLVM is API breaking).  Compatible bugfix/patch releases
can then be “dot” releases of the major number, again aligning with semantic
versioning.

The only downside I see to this is that people will think that it is crazy that
LLVM has had so many incompatible releases, but hey, why hide the truth? :-)

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