flac dev - Feb 2005 - API breakage in libflac

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.

Apologize if people feel I am flaming, but my frustration level went
rather high today as I was doing some QA work in preparation for a new
release.

Christian

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