smithjd added a comment.
In D16579#352887 <https://phabricator.kde.org/D16579#352887>, @astippich wrote: > You're doing the exact opposite of what we're asking for. > Look, I'd love to merge the bug fix for the DISC property. But we need compatibility. > I'll give you another reason: KFileMetaData has basically required that users use the DISCNUMBER field until now. And now you want to change that without providing any suitable transition. That's not user-friendly. Despite the large amount of tagger information attached to this review, it's still impossible to find a tagger that defaults to an alternative to the DISC field name for APE, Some taggers implement the ability to add arbitrary fields to APE tags, and nothing is stopping anyone from populating a DISCNUMBER field, though ignoring the more-established DISC field name is counterintuitive and this should be regarded as a specialized use-case of the APE tag. Similarly the non-standard AlbumArtist alternative to the Album Artist APE field name has been accepted (albeit as an alternative to an established field name) since about the time the disk number property was introduced. Because one of the primary motivations behind multimedia tagging is seemless portability, specialized application of APE tags should not be encouraged over existing standard field names. Forcing compliance with established tag field names is lower maintenance, and not the end of the world for KDE APE tag users. Forcing these users to adopt established field names to make full use of the KDE metadata infrastructure is a responsible thing to do anyway, and users already understand they must put effort into their tags to reap the full benefit anyway. Ending the parsing of field names that have widely-implemented counterparts should be effected with no regard for compatibility with *any* specialised application of APE tags, and with *no* transition period. KDE is very specific about the types of metadata it can make use of and requiring users to make the extra effort to get better use of its capabilities is not unreasonable. It is also not unreasonable for the user to expect that this effort would be maximally re-useable elsewhere by default. REPOSITORY R286 KFileMetaData REVISION DETAIL https://phabricator.kde.org/D16579 To: smithjd, astippich, bruns, mgallien Cc: bruns, astippich, kde-frameworks-devel, #baloo, ashaposhnikov, michaelh, spoorun, ngraham, abrahams
