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

[Stephen F. Booth]

I agree with Sander.  The time between major versions is sufficiently long that any "legacy" APIs left in for compatibility purposes will be around until 2020.  This is a great opportunity to clean up the public interface.

On Wednesday, June 5, 2013 at 8:45 PM, Sander Jansen wrote:

>  
>  
>  
> On Fri, May 24, 2013 at 11:48 AM, Scott Wheeler <scott at grunge-nouveau.net (mailto:scott at grunge-nouveau.net)> wrote:
> > On May 23, 2013, at 8:32 PM, Tsuda Kageyu <tsuda.kageyu at gmail.com (mailto: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  
> _______________________________________________
> taglib-devel mailing list
> taglib-devel at kde.org (mailto:taglib-devel at kde.org)
> https://mail.kde.org/mailman/listinfo/taglib-devel
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/taglib-devel/attachments/20130610/4dde0bab/attachment.html>