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

[Robinson, Paul via cfe-dev]

Hm.  Intriguing.  Then each release would have to specify (somehow) what its specific IR compatibility range is.
Release 47 supports bitcode back to release 3.9 (say), release 54 compatible back to release 44, etc where the "back to" number is not clearly predictable.
(This would be easier to implement if bitcode reliably had a produced-by-version number in it.)
--paulr

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chris Lattner via llvm-dev
Sent: Tuesday, June 21, 2016 9:29 PM
To: Chandler Carruth
Cc: llvm-dev at lists.llvm.org; llvm-dev-request at lists.llvm.org; Vikram Adve
Subject: Re: [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

On Jun 20, 2016, at 11:38 PM, Chandler Carruth <chandlerc at gmail.com<mailto: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/cfe-dev/attachments/20160622/b1e362bc/attachment.html>