Suggestion: some changes in String API (and source compatibility between TagLib 1 and 2)

Sander Jansen s.jansen at gmail.com
Thu Jun 6 00:45:25 UTC 2013


On Fri, May 24, 2013 at 11:48 AM, Scott Wheeler <scott at grunge-nouveau.net>wrote:

> On May 23, 2013, at 8:32 PM, Tsuda Kageyu <tsuda.kageyu at gmail.com> wrote:
>
> >
> > I suggest to make some small changes in String API.
> >
> > Currently, String class has some methods which convert itself into a
> > standard C/C++ string […]
>
>
> When I asked to bring this over to the mailing list it wasn't so much
> because of this specific commit, but to figure out to what extent it makes
> sense to try for source compatibility between TagLib 1 and TagLib 2.  Here
> was my comment there:
>
> > I agree that the suggested naming makes more sense. Some of the older
> terminology was a result of the original code being ID3 only, so it copied
> some of the terms used in the ID3v2 spec.
> >
> > One thing that is worth bringing up with a lot of these changes though
> is to what extent TagLib 2 should attempt to be source compatible with
> TagLib 1. Initially I'd assumed that they would probably be broadly
> compatible with only a handful of minor and / or obscure changes. However,
> changing something like the string export functions will naturally mean
> virtually every app using TagLib will need to be updated.
> >
> > Similar to @sbooth's comment, I think it'd probably be good to bring
> some of this stuff up on the mailing list. I've been traveling the last
> couple of weeks and haven't been able to track the most recent updates.
> While a lot of the changes do look like improvements, I'm somewhat
> concerned about API-changing decisions or possible regressions slipping in
> without review.
>
>
> I think there are three ways that this could go:
>
> - Try to preserve source compatibility for common cases, making porting
> from TagLib 1 to TagLib 2 as easy as possible
>
> - Allow all API cleanups now since TagLib 1 is now almost 10 years old and
> the TagLib 1 to 2 transition will be the last chance for API breakage for
> probably a very long time
>

My 2 cents:
I'd say go cold-turkey. If you don't, it will be a very long time before
all the old cruft is removed (considering taglib doesn't release very
often). It's a major version change, the old library should still be
install-able along side taglib2 and should provide the backward
compatibility for those who cannot upgrade yet.

Sander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/taglib-devel/attachments/20130605/80db8e3f/attachment.html>


More information about the taglib-devel mailing list