<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Jun 20, 2016, at 11:38 PM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" class="">chandlerc@gmail.com</a>> wrote:<br class=""><div><blockquote type="cite" class="">> 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.?<br class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="">
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.<br class=""></blockquote><div class=""><br class=""></div><div class="">I'm sympathetic to the idea that we should move to a sliding window for IR compatibility if that's useful.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div></div></div></blockquote><br class=""></div><div>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.</div><br class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""> - This communicates clearly and obviously to users that we changed policy with the version number scheme</div><div class=""> - Offers continuity with the prior approach (3.9 -> 40 is something that people will be able to remember)</div><div class=""> - Aligns the new version number scheme with how the project is managed</div><div class=""> - 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.</div><div class=""><br class=""></div><div class="">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? :-)</div><div class=""><br class=""></div><div class="">-Chris</div></body></html>