<div>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.</div>
<p style="color: #A0A0A8;">On Wednesday, June 5, 2013 at 8:45 PM, Sander Jansen wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><div><div dir="ltr"><br><div><br><br><div>On Fri, May 24, 2013 at 11:48 AM, Scott Wheeler <span dir="ltr"><<a href="mailto:scott@grunge-nouveau.net" target="_blank">scott@grunge-nouveau.net</a>></span> wrote:<br><blockquote type="cite"><div>On May 23, 2013, at 8:32 PM, Tsuda Kageyu <<a href="mailto:tsuda.kageyu@gmail.com">tsuda.kageyu@gmail.com</a>> wrote:<br>
<br>
><br>
> I suggest to make some small changes in String API.<br>
><br>
> Currently, String class has some methods which convert itself into a<br>
> standard C/C++ string […]<br>
<br>
<br>
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:<br>
<br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
<br>
I think there are three ways that this could go:<br>
<br>
- Try to preserve source compatibility for common cases, making porting from TagLib 1 to TagLib 2 as easy as possible<br>
<br>
- 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<br></div></blockquote><div><br></div><div style="">My 2 cents:</div>
<div>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. <br>
</div><div><br></div><div style="">Sander</div></div></div></div>
</div><div><div>_______________________________________________</div><div>taglib-devel mailing list</div><div><a href="mailto:taglib-devel@kde.org">taglib-devel@kde.org</a></div><div><a href="https://mail.kde.org/mailman/listinfo/taglib-devel">https://mail.kde.org/mailman/listinfo/taglib-devel</a></div></div></div></span>
</blockquote>
<div>
<br>
</div>