[LLVMdev] LLVM 3.4 stable releases

Tom Stellard tom at stellard.net
Mon Jan 13 15:32:50 PST 2014


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



More information about the llvm-dev mailing list