[LLVMdev] LLVM 3.4 stable releases

[Renato Golin]

On 13 January 2014 23:32, Tom Stellard <tom at stellard.net> wrote:

> 1. Get volunteers to help
>

I'm available to do point release builds and tests, as I do for releases.


3. Make sure this page: http://llvm.org/docs/ReleaseProcess.html is updated
> and
>
  correct:
>

I may have to add a few things... but nothing serious.


4. Come up with a list of all the platforms which must be tested in
>    order to make a release.
>

So, this depends on who is available at the time the point release comes
out. The work Bill did to organize all this was not small, and it takes
time to do it all, and people take holidays, move jobs, etc.

Until we have an official commitment from companies that care about LLVM,
in which someone should always be available to do the release from that
company, we can't commit ourselves to anything. If you remember the
official release process and the number of binaries released, there was
nothing "official" about that process either.


5. Determine whether or not stable releases should maintain a stable ABI.
>

As I said earlier, I think this is paramount.

What this means is that building blocks will remain compatible with the
release, as to minimise re-compilation of out-of-tree projects.

I can think of things like IRBuilder, DIBuilder, APInt, StringRef, but also
the Debug Information metadata format, IR semantics, pass order,
command-line options, etc.

In essence, release 3.4.1 should have nothing more than bug fixes to
existing infrastructure, either crashes, conformance or performance, but
never change the semantics.


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

AFAICR, the LSB uses symlinks like:

libLLVM-3.4.so -> libLLVM-3.4.so.3
libLLVM-3.4.so.3 -> libLLVM-3.4.so.3.4.1
libLLVM-3.4.so.3.4 (deprecated)
libLLVM-3.4.so.3.4.1

I'm not sure LLVM does any of that, but we'd have to do something similar
if we are to add point releases.


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'd say we only do a release if a serious enough bug shows up after we
release LLVM. I wouldn't go for performance reviews right now because
that's impossible to manage at our level of commitment.

We cannot test all programs in all platforms. We cannot benchmark all
benchmarks on all platforms. We may not even be able to compile it for all
platforms...

For those reasons, it's impossible to ascertain the quality of any revision
after the official release unless you do the release process every time,
which won't happen because it takes three months to do so.


* My Impressions

If I got it right, you're referring to a different kind of point release,
just checking out a release and testing it, as if it was just another
release in between. I personally see no value in doing so. The only value
is to backport bug-fixes into the original branch-3.4 and make a release
for production systems that have tested 3.4 and need a bug fixed.

My reasoning is this:

 1. The LLVM community follows trunk. All developers, all out-of-tree
developers and all libraries and sub-projects do so. There is no point in
marking release A or B when no one even cares about releases.

 2. Users that need stability (Google for Renderscript, Apple of iOS, etc)
get a random revision, test it thoroughly, fix a few bugs directly, and
ship. No one, AFAIK, uses or depend on any specific release of LLVM. We do
releases more to track conformance and performance than anything else.

 3. Users that do need a specific release (research projects, proprietary
R&D) will stick to a release and not change for years. Three months won't
make any difference for them, and they will only move to a newer version if
there is a significant feature added or bug fixed.

For those reasons, releasing anything bug bug-fixes in between releases is
not just unnecessary, but a waste of time. Besides, buildbots already do
most of this job (compile checks, test-suites, etc), so if you do want to
release a revision, I'd advise you to do so unofficially and based on
buildbot status.

If you're instead, referring to bug-fix releases, than backporting specific
commits to the old branch won't generally break any API or semantics, and
it should be safe for us to test and ship. Also, it should only take one
cycle of tests, since there won't be many changes and most of it was
already tested on release anyway.

Makes sense?

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140114/97ac72e1/attachment.html>