[LLVMdev] [cfe-dev] LLVM 3.4 Branch Freeze
Pau Garcia i Quiles
pgquiles at elpauer.org
Thu Dec 19 11:55:12 PST 2013
On Thu, Dec 19, 2013 at 8:15 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> > > the other thing we need to determine is
> > > > whether or not we want to maintain a stable ABI for the bugfix
> > > > releases.
> > > > With 3.3, the plan was to have a stable ABI, but this caused me
> > > > to reject several fixes. I would recommend relaxing this
> > > > requirement if there is are bugfix releases for 3.4, but I'd like to
> hear
> > > > what other people think about this.
> > >
> > > What kinds of changes were made? (can you provide a couple of
> > > examples)?
> > >
> >
> > Here are a few examples:
> > http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/157018
>
> I think that we should keep source compatibility, not necessarily binary
> compatibility, in maintenance releases. Binary compatibility, when
> possible, is nice, but should not stand in the way of the bug fixes
> themselves.
>
> Some of the packagers should comment on this topic :)
>
>
Breaking ABI in patch releases with no other changes?
As a Debian packager (but not LLVM packager), I am opposed to changing ABI
without bumping soversion and changing library name. If we have this:
LLVM 3.4.0 => libclang-3.4.so.1
LLVM 3.4.1 => libclang-3.4.so.1 (same)
but they are ABI-incompatible, that's going to cause trouble.
But if we have this:
LLVM 3.4.0 => libclang-3.4.so.1
LLVM 3.4.1 => libclang-3.4.so.2 (soname bumped)
that's perfectly fine
(I guess everybody here knew that already...)
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131219/dd9caf27/attachment.html>
More information about the llvm-dev
mailing list