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 <[EMAIL PROTECTED]> 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 _______________________________________________ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
