[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] ABI problem with: [PATCH v2] add multi extent ISO966

From: Rocky Bernstein
Subject: Re: [Libcdio-devel] ABI problem with: [PATCH v2] add multi extent ISO9660 file support to libcdio
Date: Wed, 27 Jun 2018 14:52:58 -0400

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
> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]