<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 13 January 2014 23:32, Tom Stellard <span dir="ltr"><<a href="mailto:tom@stellard.net" target="_blank">tom@stellard.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
1. Get volunteers to help<br></blockquote><div><br></div><div>I'm available to do point release builds and tests, as I do for releases.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
3. Make sure this page: <a href="http://llvm.org/docs/ReleaseProcess.html" target="_blank">http://llvm.org/docs/ReleaseProcess.html</a> is updated and<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
correct:<br></blockquote><div><br></div><div>I may have to add a few things... but nothing serious.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
4. Come up with a list of all the platforms which must be tested in<br>
order to make a release.<br></blockquote><div><br></div><div>So, this depends on who is available at the time the point release comes out. The work Bill did to organize all this was not small, and it takes time to do it all, and people take holidays, move jobs, etc. </div>
<div><br></div><div>Until we have an official commitment from companies that care about LLVM, in which someone should always be available to do the release from that company, we can't commit ourselves to anything. If you remember the official release process and the number of binaries released, there was nothing "official" about that process either.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">5. Determine whether or not stable releases should maintain a stable ABI.<br>
</blockquote><div><br></div><div>As I said earlier, I think this is paramount.</div><div><br></div><div>What this means is that building blocks will remain compatible with the release, as to minimise re-compilation of out-of-tree projects.</div>
<div><br></div><div>I can think of things like IRBuilder, DIBuilder, APInt, StringRef, but also the Debug Information metadata format, IR semantics, pass order, command-line options, etc.</div><div><br></div><div>In essence, release 3.4.1 should have nothing more than bug fixes to existing infrastructure, either crashes, conformance or performance, but never change the semantics.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">7. Figure out the .so name to use for stable releases (i.e. Should we<br>
use <a href="http://libLLVM-3.4.so" target="_blank">libLLVM-3.4.so</a> or <a href="http://libLLVM-3.4.1.so" target="_blank">libLLVM-3.4.1.so</a>)<br></blockquote><div><br></div><div>AFAICR, the LSB uses symlinks like:</div>
<div><br></div><div><a href="http://libLLVM-3.4.so">libLLVM-3.4.so</a> -> libLLVM-3.4.so.3</div><div>libLLVM-3.4.so.3 -> libLLVM-3.4.so.3.4.1<br></div><div>libLLVM-3.4.so.3.4 (deprecated)<br></div><div>libLLVM-3.4.so.3.4.1<br>
</div><div><br></div><div>I'm not sure LLVM does any of that, but we'd have to do something similar if we are to add point releases.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
9. Choose a release date for LLVM 3.4.1<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
My recommendation is to release LLVM 3.4.1 3 months after 3.4 and have it<br>
be the only stable release. Once we get better as a community at doing<br>
stable releases, then maybe we can consider doing more.<br></blockquote><div><br></div><div>I'd say we only do a release if a serious enough bug shows up after we release LLVM. I wouldn't go for performance reviews right now because that's impossible to manage at our level of commitment.</div>
<div><br></div><div>We cannot test all programs in all platforms. We cannot benchmark all benchmarks on all platforms. We may not even be able to compile it for all platforms...</div><div><br></div><div>For those reasons, it's impossible to ascertain the quality of any revision after the official release unless you do the release process every time, which won't happen because it takes three months to do so.</div>
<div><br></div><div><br></div><div>* My Impressions</div><div><br></div><div>If I got it right, you're referring to a different kind of point release, just checking out a release and testing it, as if it was just another release in between. I personally see no value in doing so. The only value is to backport bug-fixes into the original branch-3.4 and make a release for production systems that have tested 3.4 and need a bug fixed.</div>
<div><br></div><div>My reasoning is this:</div><div><br></div><div> 1. The LLVM community follows trunk. All developers, all out-of-tree developers and all libraries and sub-projects do so. There is no point in marking release A or B when no one even cares about releases.</div>
<div><br></div><div> 2. Users that need stability (Google for Renderscript, Apple of iOS, etc) get a random revision, test it thoroughly, fix a few bugs directly, and ship. No one, AFAIK, uses or depend on any specific release of LLVM. We do releases more to track conformance and performance than anything else.</div>
<div><br></div><div> 3. Users that do need a specific release (research projects, proprietary R&D) will stick to a release and not change for years. Three months won't make any difference for them, and they will only move to a newer version if there is a significant feature added or bug fixed.</div>
<div><br></div><div>For those reasons, releasing anything bug bug-fixes in between releases is not just unnecessary, but a waste of time. Besides, buildbots already do most of this job (compile checks, test-suites, etc), so if you do want to release a revision, I'd advise you to do so unofficially and based on buildbot status.</div>
<div><br></div><div>If you're instead, referring to bug-fix releases, than backporting specific commits to the old branch won't generally break any API or semantics, and it should be safe for us to test and ship. Also, it should only take one cycle of tests, since there won't be many changes and most of it was already tested on release anyway.</div>
<div><br></div><div>Makes sense?</div><div><br></div><div>cheers,</div><div>--renato</div></div></div></div>