[LLVMdev] LLVM 3.4 stable releases

Sylvestre Ledru sylvestre at debian.org
Thu Jan 16 10:20:38 PST 2014

On 14/01/2014 00:32, Tom Stellard wrote:
> Hi,

> 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.
Count me in.
> 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.
I would have been interested a few months ago but since I am going to
start a new job next Tuesday.
I don't think that would be reasonable.
> 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?
>From the distro pov, all libraries depending on LLVM or clang libraries.
That is starting to be important.
If you change the ABI, we, distribution, would have to rebuild all
packages depending on
LLVM & Clang. If we keep the same ABI, this work won't be necessary.
Changing an ABI is really a nightmare from the distribution point of view...
> 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)

libLLVM-3.4.so should be OK if the ABI does not change.

> 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 am not sure that it is about date but more about the number of
critical bugs in the current stable release...

I would add a 10) point.
Clearly document what kind of patches are acceptable from a stable release.

For me, it should be only important bug fixes, no new feature.


More information about the llvm-dev mailing list