Re: [Libcdio-devel] ABI problem with: [PATCH v2] add multi extent ISO9660 file support to libcdio

[Adrian Reber]

As the Fedora package maintainer I am used that each libcdio release
comes with a new SO version. It is always additional work to update the
libcdio package as I have to make sure all dependencies are rebuilt.

This is also the reason I am (almost) never updating libcdio in a
released version of Fedora, besides cherry-picking patches for smaller
fixes.

So I would prefer a release which does not break ABI. But as I am used
to rebuilding all libcdio dependencies with every release it would not
be a big problem.

Breaking API would be more difficult as this requires new releases from
all application using the old API and this could increase the time until
I can package the latest version.

                Adrian

On Wed, Jun 27, 2018 at 02:52:58PM -0400, Rocky Bernstein wrote:
> Sounds reasonable.
> 
> I have a question though - to everyone:  What are thoughts around a release
> schedule? What would a reasonable roadmap be? a
> 
> The next release will include the CD-TEXT changes but not the multi-extent
> changes? And will be ABI and API compatible? Or not?
> 
> And then we the release after that we are planning to break compatability?
> 
> I'm not trying to push this one way or another, but ratther to start a
> discussion of what should go in when.
> 
> I am concerned that changing the API/ABI too quickly that it doesn't give
> distributions time to adjust. So, folks who work on the distributions,
> please chime in or suffer the consequences of  whatever happens.
> 
> The problem with working on a library that other applications depend on is
> that to upgrade the library you have redo those applications and that can
> be a bit of work..
> 
> On Wed, Jun 27, 2018 at 2:35 PM, Thomas Schmitt <address@hidden> wrote:
> 
> > Hi,
> >
> > i wrote:
> > > > Currently i am not sure whether an API extension would be that much
> > more
> > > > development work
> >
> > Pete Batard wrote:
> > > In that case, I'm going to respectfully ask someone else to do that work,
> > > because I have spent about as much time as I can allocate to adding
> > > multi-extent support to mainline libcdio.
> >
> > Well, instead of committing ritual suicide because of
> >   https://www.nytimes.com/2018/06/27/sports/world-cup/
> > germany-vs-south-korea.html
> > i might give it a try.
> >
> > My plan is to:
> >
> > - Switch to branch pbatard-multiextent2.
> >   Create a new branch ts-multiextent in the hope to inherit Pete's work.
> >
> > - Change iso9660_stat_s.extent_lsn and iso9660_stat_s.extent_size
> >   to dynamically allocated memory (with proper destruction).
> >
> >   Commit for a still ABI incompatible state with less memory waste.
> >
> > - Rename existing mixed API function implementations iso9660_*_stat*() to
> >   new names iso9660_*_statv2*().
> >   Derive iso9660_statv2_s from iso9660_stat_s + DO_NOT_WANT_COMPATIBILITY.
> >   Remove multi-extent stuff from iso9660_stat_s.
> >   Implement old API functions again as mere frontends to the renamed
> >   functions.
> >   Expose iso9660_*_statv2*() calls which hand out iso9660_statv2_s.
> >   Implement and expose access functions for members of iso9660_statv2_s.
> >
> >   Commit for ABI compatible state.
> >
> > Does this sound reasonable ? Especially the first step with git wizzardry ?
> >
> >
> > Have a nice day :)
> >
> > Thomas