LLVM 3.4 stable releases

Project Infrastructure LLVM Dev List Archives
21

What's the state here?

There are three commits I've made to Clang that I'd like to see in the 3.4
release branch if for no other reason than to help out folks bootstrapping
on old Linux distributions with too-old installed versions of
GCC/libstdc++. These are r199632, r199633, and r199769. Let me know if you
can merge them or I should or how we can get a nice stable tree that folks
can check out and build as the first step of getting a bootstrap.

Hi Chandler,

I think we can start committing patches to the 3.4 branch even while
we finalize the details of the release process. Assuming these patches
fall into the category of ABI compatible bug fixes, if you cc me and the
code owner on theses commit emails, I can commit them to the 3.4 branch
once the code owner approves.

-Tom

22

Hi,

I've updated these points based on recent feedback. I'll update
the documentation to reflect these if there are no objections:

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 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.

-Tom