[LLVMdev] LLVM 3.4 stable releases

[Tom Stellard]

On Thu, Jan 16, 2014 at 12:53:21PM -0600, Hal Finkel wrote:
> ----- Original Message -----
> > From: "Sylvestre Ledru" <sylvestre at debian.org>
> > To: "Tom Stellard" <tom at stellard.net>, llvmdev at cs.uiuc.edu
> > Cc: "erik verbruggen" <erik.verbruggen at me.com>
> > Sent: Thursday, January 16, 2014 12:20:38 PM
> > Subject: Re: [LLVMdev] LLVM 3.4 stable releases
> > 
> > On 14/01/2014 00:32, Tom Stellard wrote:
> > > Hi,
> > 
> > > 1. Get volunteers to help
> > >
> > > This is probably the most important thing on this list.  Stable
> > > releases
> > > need to be a community effort, there is too much work for just a
> > > few people to
> > > do.
> > Count me in.
> 
> Me too! Tom, thanks for doing this!
> 
> > >
> > > 2. Choose a release manger.
> > >
> > > I will volunteer for this, but if someone else wants to do it, I
> > > have no
> > > problem relinquishing the role.
> 
> I'm certainly willing to help with this (I'm a bit hesitant to say that I'll do it, because I'm not sure what's involved with actually creating the binaries). I'll certainly help with culling the bug fixes to be back ported into the stable branch.

I think usually the testers are responsible for creating the binaries.
The release manager is in charge of committing the patches to the stable
branch and also making sure the release process guidelines are being
followed.

I think tracking down all the bug-fixes could be difficult, so it would be
good to have several people helping with this.

-Tom
> 
> > I would have been interested a few months ago but since I am going to
> > start a new job next Tuesday.
> > I don't think that would be reasonable.
> > > 4. Come up with a list of all the platforms which must be tested in
> > >    order to make a release.
> > >
> > > 5. Determine whether or not stable releases should maintain a
> > > stable ABI.
> > >
> > > It seems like the preference in the community is to keep a stable
> > > ABI
> > > with stable releases.  I'm curious what uses cases require a stable
> > > ABI?
> > From the distro pov, all libraries depending on LLVM or clang
> > libraries.
> > That is starting to be important.
> > If you change the ABI, we, distribution, would have to rebuild all
> > packages depending on
> > LLVM & Clang. If we keep the same ABI, this work won't be necessary.
> > Changing an ABI is really a nightmare from the distribution point of
> > view...
> > > 6. Add patch level to LLVM version (e.g. 3.4.0)
> > >
> > > 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)
> > 
> > libLLVM-3.4.so should be OK if the ABI does not change.
> 
> +1
> 
> But, we might also want to symlink a libLLVM-3.4.1.so to it; that way if you ship a binary that depends on some bug fix in 3.4.1 (and explicitly link against 3.4.1), it can't accidentally be run in an environment with only 3.4 (obviously, there are other ways to do this, but that seems the simplest).
> 
> > 
> > >
> > > 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 am not sure that it is about date but more about the number of
> > critical bugs in the current stable release...
> > 
> > 
> > I would add a 10) point.
> > Clearly document what kind of patches are acceptable from a stable
> > release.
> > 
> > For me, it should be only important bug fixes, no new feature.
> 
> I think we should take bug fixes, generally, (crashes and especially miscompiles), but only those that are did not involve any significant amount of refactoring (or are tied to new features).
> 
>  -Hal
> 
> > 
> > Sylvestre
> > 
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > 
> 
> -- 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory