[LLVMdev] LLVM 3.4 stable releases

[Tom Stellard]

On Mon, Jan 20, 2014 at 04:06:04PM +0000, Renato Golin wrote:
> On 20 January 2014 15:44, Tom Stellard <tom at stellard.net> 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:
> >
> 
> Hi Tom,
> 
> Thanks for the summary, I agree with mostly everything, but I have some
> specific comments inline...
> 
> 
> + Shared library name will remain libLLVM-Major.Minor.so, but
> >
>   a libLLVM-Major.Minor.Patch.so symlink will be added.
> >
> 
> You mean a library M.m.p will be created and a symlink M.m will point to
> it, right?
> 

Yes.

libLLVM-M.m.so -> libLLVM-M.m.p.so

> 
> + Supported platforms will be determined by test coverage.
> >
> 
> I'm in two minds about it. While it makes no sense to re-build for all
> archs if the bug-fix is specific to only one, it'll confuse people if you
> need to use the same toolchain across different architectures, and we'll
> end up replying on the list: "oh, 3.5.1 is only for ARM and x86, while
> 3.5.2 is only for Mips...", etc. I think we should release all binaries,
> and maybe test less extensively on the architectures that have no
> bug-fixes, but still build the binaries, the libraries, and symlinks.
> 

How many people actually depend on the binaries posted on llvm.org?  I
agree that if we are providing binaries we should try to build binaries
for the same architectures each release. However, it seems to me like a
majority of LLVM's users are using a binary produced somewhere else, so
I wonder if we even need to worry about which architectures we build for.

I'm much more concerned about platform testing and validation than I am
the binaries.

> The problem arises when no one will build and test for arch A and we simply
> cannot release something without even knowing it runs. We shouldn't stop
> the release because of that, and that would be an acceptable case where
> there simply is no patch-release for that arch. I would expect it not to
> happen for the architectures listed as "supported" in the documentation,
> and in time, it should be "frowned upon" for "supported" architectures NOT
> to do a patch release.
> 
>

What you've described is the main problem I'm trying to avoid.  Where we say we
support ARM, for example, and then there is a critical fix for X86 somewhere
in the core libraries, and we can't do a release because there are no ARM testers
to build binaries.

As far as I understand, there only two "supported" or "first-tier" platforms:
X86 and ARM.  I just want it to be clear what to do in case there are no testers
for one of these platforms.  Do we cancel the release, or do we take the position
that if no one is willing to provide testing resources for a platform, then it
is not really worthy of "supported" or "first-tier" status.

-Tom
 
> cheers,
> --renato