Re: [Libcdio-devel] RFC: Two releases or one?

[Rocky Bernstein]

On Wed, Feb 22, 2012 at 2:21 PM, Leon Merten Lohse <address@hidden>wrote:

> Hi,
>
> actually there are a few more changes I did not commit yet including
> support for all 8 blocks and a rewritten parser routine that does not
> rely on shady gcc features (packed pragma, bitfields).
> I implemented some new aspects of CD-TEXT that required new functions.
> In order to keep the code as clean as possible I changed the internal
> data structure so that there is just one CD-TEXT struct and not one for
> every track, because the latter does not make any sense. Either there is
> CD-TEXT on the disc or there is not. There cannot be CD-TEXT for just a
> few tracks.
> All the libcdio CD-TEXT functions work on a CD-TEXT object. It would
> have been a pain to rewrite the existing functions to work with the new
> data structure and again imho it did not make any sense the way it was.


I understand (or gather) that C structures have changed. However,
can you briefly describe the incompatibilities from the standpoint of
someone using the library? Perhaps something like:  this is how you'd do
something previously and now this is how you do things and how the old way
was deficient in some aspect.

A peripheral look at things just turned up that subroutines like
"cdtext_get" "cdtext_get_const", "cdtext_set"  now takes a track
parameter.  It seemed to me that instead of using the old name, one could
have used a different name (like "cdtext_get_by_track", although that name
itself might be a bit long), and to be compatible have cdtext_get just fill
in track and call the new routine like cdtext_get_by_track(key, 0, ...)

What am I missing?

More generally though although one can look at breaking compatibility as a
binary thing - it's the same or not - I see variations in between such as
by using new names or providing compatibility where it is not too much of a
burden.



> So since I did not know of any program really using libcdio's CD-TEXT I
> think the loss was not too big.
>

What I think would be great is if you and Nicolas could come to a common
understanding or agreement on this is the best we can do given the current
circumstances (i.e. flaws of the previous release of libcdio and amount of
effort it would take to be compatible)

Thanks.


>
> I plan to commit the last api changes (language selection) this weekend.
> This way it is going to be a single rather big incompatible change.
>
> If you have objections, I can try to write a workaround but it is not
> going to be pretty and will not help making the api easier.
>
> Regards
> Leon
>
> On Wed, Feb 22, 2012 at 05:08:15PM +0100, Nicolas Boullis wrote:
> > On Mon, Feb 20, 2012 at 05:56:32PM -0500, Rocky Bernstein wrote:
> > >
> > > The new cdtext_get() adds a parameter for the track. I suppose we could
> > > have and added a new routine rather than modify the old one in an
> > > incompatible way.
> > >
> > > I don't have strong feelings on this. Perhaps Leon could comment.
> >
> > With my Debian hat on, I prefer when there is no incompatible change, at
> > least for the binary interface.
> > Each time the binary interface of a lirary changes incompatibly, the
> > SONAME has to change, and all programs that use this library must be
> > rebuilt.
> > Currently, the number of programs that use libcdio is not too huge (at
> > least within the programs provided by Debian). But the more libcdio will
> > be adopted the more complex those transitions will be...
> >
> >
> > > I had considered one branch having
> > >   * paranoia removed
> > >   * cd-text changes
> > >   * whatever compatible UDF/Joliet/Rock Ridge fixes
> > >
> > > And in another the incompatible header changes plus whatever the
> > > UDF/Joliet/Rock Ridge changes aren't
> > > in the first release.
> >
> > As far as I understand it, I see no reason to want 2 releases.
> >
> >
> > --
> > Nicolas
> >
>
>