[Flac-dev] API breakage in libflac

[Josh Coalson]

sorry about the delay, looks like this mail just made it through
moderation (at least today is when I got it)

--- Christian Fredrik Kalager Schaller <uraeus at linuxrising.org> wrote:
> Hi,
> The GStreamer flac plugin broke due to libflac 1.1.0 and libflac
> 1.1.1
> not being ABI/API compatible. Skimming through the archives I see
> that
> this breakage was intentional. I think it is quite common
> understanding
> that when you have a stable release of something you don't break your
> API, you only add to it. If you want to break the API that should be
> done by going to a new major number, like libflac 2.0 and ideally
> make
> the two versions parallel installable. 
> 
> There are a lot of packages depending on libflac today and I ended up
> having to deinstall a lot of stuff in order to install the new
> version
> of libflac as we have now updated our plugin to the new API.
> 
> But for the future please be serious about API stability as you are
> really screwing developers and packagers depending on you by changes
> like this.
> 
> It could of course be that libflac 1.1.x is not considered a stable
> release series and that the world should have stuck with libflac
> 1.0.x
> for now, but nothing on your website gives me this impression and I
> guess since most distros ship 1.1.x now it means that they too assume
> it
> is a stable release series.

maybe this is not the right way to do it, but FLAC release
numbers are not related to the API version, they are related
to the format version.  major version number changes break
backward compatibility with the format (i.e. decoder will not
play older streams), minor version number changes break
forward compatibility (i.e. older decoders cannot play some
streams encoded by current encoder), and micro version number
changes are forward and backward compatible.

the kind of API versioning you are talking about is captured
in the libtool version numbers which translate into the soname.

for users, the former numbering scheme is what is important.  I
can see how this makes it harder for people using the API and
used to other numbering systems.  I don't know how to resolve
this.

why aren't the libtool versions enough to be parallel-installable?
is it only a problem getting package dependencies right with rpm?
or maybe it is with the -devel packages, since includes always
go into .../include/FLAC and so they can't be parallelized?

Josh


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com