[LLVMdev] LLVM 3.4 stable releases

Tom Stellard tom at stellard.net
Mon Jan 20 07:44:12 PST 2014


Hi,

Thanks for the feedback.  Here is a summary of the responses.
These items are still up for discussion, but if there are no
objections in the next few days, I will add these to the
release documentation:

+ Stable release must be ABI compatible with the current major
  release.

+ Only bug fixes will be accepted in stable releases.  All changes
  to the stable branch must first be committed to trunk (when applicable)
  and approved by the code appropriate code owner.

+ Shorter release cycle with 1 release candidate.

+ Shared library name will remain libLLVM-Major.Minor.so, but
  a libLLVM-Major.Minor.Patch.so symlink will be added.

+ Supported platforms will be determined by test coverage.

+ The release manager will determine when to make a stable release based
  on input from the community.  This will be a judgement call, but
  the basic guidelines are to do a release if there are a large number
  of bug-fixes sitting in the stable branch or some critical bugs are
  found after a release that affect a large number of users.

TODO list:

+ Add patch level to LLVM version.
+ Add support for stable releases to test-release.sh script.
+ Update testing and release documentations.
+ Identify candidate patches for the stable branch. 

-Tom


On Mon, Jan 13, 2014 at 03:32:50PM -0800, Tom Stellard wrote:
> Hi,
> 
> I would like to try again to do stable releases for LLVM 3.4.
> Even though we were unsuccessful with stable releases for LLVM
> 3.3, I learned some things going through the process, which I think
> will increase the chance for success with LLVM 3.4.
> 
> So, here is my TODO list for a successful 3.4.1 release:
> 
> 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.
> 
> 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.
> 
> 3. Make sure this page: http://llvm.org/docs/ReleaseProcess.html is updated and
>   correct:
> 
> It would be great if someone who just participated in the release process could
> look over this page and make sure it is correct and easy to follow.  For example,
> to me it's not clear how to compare the results of the test-release.sh script from
> different release candidates.
> 
> 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?
> 
> 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)
> 
> 8. Add support for stable releases to the test-release.sh script.
>    This may go along with adding the patch level to LLVM version.
> 
> 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 think this list is a good starting point.   Anyone else have any ideas
> or other feedback?
> 
> Thanks,
> Tom
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



More information about the llvm-dev mailing list