[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libcdio-devel] [RFC/PATCH] add multi extent ISO9660 file support to
From: |
Rocky Bernstein |
Subject: |
Re: [Libcdio-devel] [RFC/PATCH] add multi extent ISO9660 file support to libcdio |
Date: |
Wed, 13 Jun 2018 17:25:07 -0400 |
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
>
>
>