[LLVMdev] LLVM 3.4 stable releases

[Tom Stellard]

On Tue, Jan 14, 2014 at 03:57:25PM +0000, Renato Golin wrote:
> On 13 January 2014 23:32, Tom Stellard <tom at stellard.net> wrote:
> 
> > 1. Get volunteers to help
> >
> 
> I'm available to do point release builds and tests, as I do for releases.
> 
> 
> 3. Make sure this page: http://llvm.org/docs/ReleaseProcess.html is updated
> > and
> >
>   correct:
> >
> 
> I may have to add a few things... but nothing serious.
> 
> 
> 4. Come up with a list of all the platforms which must be tested in
> >    order to make a release.
> >
> 
> 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.
> 
> 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.
> 
> 
> 5. Determine whether or not stable releases should maintain a stable ABI.
> >
> 
> As I said earlier, I think this is paramount.
> 
> What this means is that building blocks will remain compatible with the
> release, as to minimise re-compilation of out-of-tree projects.
> 
> 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.
> 
> 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.
> 
> 
> 7. Figure out the .so name to use for stable releases (i.e. Should we
> > use libLLVM-3.4.so or libLLVM-3.4.1.so)
> >
> 
> AFAICR, the LSB uses symlinks like:
> 
> libLLVM-3.4.so -> libLLVM-3.4.so.3
> libLLVM-3.4.so.3 -> libLLVM-3.4.so.3.4.1
> libLLVM-3.4.so.3.4 (deprecated)
> libLLVM-3.4.so.3.4.1
> 
> I'm not sure LLVM does any of that, but we'd have to do something similar
> if we are to add point releases.
> 
> 
> 9. Choose a release date for LLVM 3.4.1
> >
> 
> > My recommendation is to release LLVM 3.4.1 3 months after 3.4 and have it
> > be the only stable release.  Once we get better as a community at doing
> > stable releases, then maybe we can consider doing more.
> >
> 
> 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.
> 
> 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...
> 
> 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.
> 
> 
> * My Impressions
> 
> 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.
> 

Sorry this wasn't clear.  My assumption was that we would be backing-porting
fixes from master to 3.4 and making a release from the 3.4 branch.

> My reasoning is this:
> 
>  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.
> 
>  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.
> 
>  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.
> 
> 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.
> 
> 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.
> 
> Makes sense?
> 
> cheers,
> --renato