Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Tom Stellard <tom <at> stellard.net>
Subject: Re: LLVM 3.4 stable releases
Newsgroups: gmane.comp.compilers.llvm.devel
Date: Friday 24th January 2014 21:53:04 UTC (over 3 years ago)
Hi,

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:
> 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
 
CD: 3ms