Re: [Libcdio-devel] [RFC/PATCH] add multi extent ISO9660 file support to libcdio

[Rocky Bernstein]

On Wed, Jun 13, 2018 at 7:09 AM, Thomas Schmitt <address@hidden> 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
>
>
>