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

Scott Wheeler scott at grunge-nouveau.net
Fri May 24 16:48:59 UTC 2013


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

- Do like Qt often does in major version changes and include compatibility functions in the API that are marked as deprecated.

Thoughts?

-Scott


More information about the taglib-devel mailing list