[LLVMdev] LLVM 3.4 stable releases
tom at stellard.net
Fri Jan 24 13:53:04 PST 2014
I've updated these points based on recent feedback. I'll update
the documentation to reflect these if there are no objections:
On Mon, Jan 20, 2014 at 07:44:12AM -0800, Tom Stellard wrote:
> 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
> + 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 be libLLVM-Major.Minor.Patch.so and it will be
pointed to by a symbolic link called libLLVM-Major.Minor.so. e.g.
libLLVM-Major.Minor.so -> libLLVM-Major.Minor.Patch.so
+ Before a release can be made, the unit test suite must be run
with no regressions compared to the previous release on all three
"tier one" platforms: X86, X86_64, and ARM.
+ Candidate patches for the stable branch will be nominated by replying
to the llvm-commits email generated when the patch was committed to ToT
and cc'ing the code owner and release manager.
If for some reason there is no corresponding fix committed to ToT,
patches can be nominated by emailing them to the release manager,
code owner, and llvm-commits mailing list.
Patches must be approved by both the release manager and the code
owner before they can be committed to the stable branch.
> + 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.
+ Explore a better method for keeping track of stable bug-fixes. A few ideas:
- Add a tag to the subject of the email when submitting a patch:
e.g. [PATCH 3.4.1]
- Create a llvm-stable mailing list for stable patches
- Add an annotation when committing fixes to master in order to
indicate that they should be backported to the stable branch.
More information about the llvm-dev