On Wed, Jun 13, 2018 at 7:09 AM, Thomas Schmitt <[email protected]> wrote:
> Hi, > > Rocky Bernstein wrote: > > Now that the dust has settled, (and before too much more settles) Thomas' > > changes have now been merged into master. > > My patches belong to another discussion thread: > "[Libcdio-devel] RFC on two CD-TEXT patches by Serge Pouliquen" > http://lists.gnu.org/archive/html/libcdio-devel/2018-05/msg00000.html > ... > http://lists.gnu.org/archive/html/libcdio-devel/2018-05/msg00006.html > https://savannah.gnu.org/bugs/?53928 > > The commit > "Merge branch 'cdtext-list-languages'" > http://git.savannah.gnu.org/cgit/libcdio.git/commit/?id= > 16ff26506eedd748598f2beed4aa9825d04c1c9f > not only contains my changes about CDTEXT but also new files which were > not made by me (at least not this year): > > conf9AaqoM/subs.awk > conf9AaqoM/subs1.awk > config_extract.sh > example/read-disc-struct.c > example/read-disc-struct.sh > test/copying.iso > test/driver/abs_path.dSYM/Contents/Info.plist > test/driver/abs_path.dSYM/Contents/Resources/DWARF/abs_path > test/driver/gdb.core > test/driver/mmc_read.core > test/iso-info.core > Hmm... this is my mistake. Thanks for pointing this out. I'm not sure how those crept in, but I've removed all except config_extract.sh which seems marginally useful. > > > With the various API changes, expect a discussion on what the next > version > > number will be, and how and the various library major/minior/version > > numbers. > > In my own libraries the change would count as API and ABI compatible > with no special consequences for version numbers. > That might be true for the semantic version number of the package, but I am not sure this is relevant for for the libtool dynamic library version number. My understanding of the rules written by Nicholas Boullis is ound in libhttp:// git.savannah.gnu.org/cgit/libcdio.git/tree/lib/driver/Makefile.am?id=16ff26506eedd748598f2beed4aa9825d04c1c9f#n30 which in part reads: # 3. If the library source code has changed at all since the last # update, then increment REVISION (`C:R:A' becomes `C:R+1:A'). # # 4. If any interfaces have been added, removed, or changed since the # last update, increment CURRENT, and set REVISION to 0. # # 5. If any interfaces have been added since the last public release, # then increment AGE. # # 6. If any interfaces have been removed or changed since the last # public release, then set AGE to 0. A changed interface means an # incompatibility with previous versions. Rule 3: library source change so we increment REVISION, but by Rule 4: interfaces have been added so we increment CURRENT and set REVISION to 0 and by Rule 5: itnerfaces have been added so we increment AGE I think right now Rule 6 doesn't apply. So in total, the current C:R:A becomes C+1:0:A+1 for lib/driver. I believe the other drivers are not effected, but then there's Pete's change which are in lib/iso9660. > Old applications will continue to work as good or bad as they did before. > If such an application runs into the shortcommings of the deprecated > function cdtext_list_languages(), then the answer to a bug report will be: > Use cdtext_list_languages_v2() and cdtext_set_language_index() > instead of cdtext_list_languages() and cdtext_select_language(). > > cdtext_select_language() is not deprecated generally. But it assumes a > set of language blocks with all valid and unique language codes. > cdtext_set_language_index() does not depend on such a nice situation. > > > Have a nice day :) > > Thomas > > >
