[Top][All Lists]

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

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

From: Rocky Bernstein
Subject: Re: [Libcdio-devel] RFC: Two releases or one?
Date: Tue, 21 Feb 2012 07:51:56 -0500

On Mon, Feb 20, 2012 at 9:45 AM, Pete Batard <address@hidden> wrote:

> On 2012.02.20 12:45, Rocky Bernstein wrote:
>> There have a few larger unrelated changes that taken place and I would
>> like
>> to solicit opinions on whether we should have one release with all of the
>> changes or two?
>> The changes are
>> * CD-Text completion (some incompatibility)
>> * UDF improvement and header reworking for Microsoft OS's
>> * Removal of cd-paranoia which is be in now in a separate GPL v2+
>> directory
>> * Various bug fixes
>> Comments?
> Note that on top of that, I have recently added some Joliet fixes (as well
> as some addressing of the TODOs with regards to falling back to non Joliet
> if the string is the same but potentially larger - see [1] and [2]).
> The main issue was that some ISO9660 discs may have multiple Secondary
> Volume Descriptors (eg: El Torito + Joliet) and the existing code only
> handled the very first one for Joliet.
> I also had to amend the fixes for MSVC UDF compatibility, as I discovered
> that in the Microsoft world, an union of zero-sized arrays is not zero
> bytes as expected (and as is the case for GNU), but one byte. This created
> a problem with file entries as the MSVC sizeof was off (but this was only
> an issue for MSVC compiled code). This only has an impact for UDF [3], but
> renders the header workarounds required for MSVC slightly more
> in-your-face, as we now need to attach the MSVC required unions to a
> non-empty member.
> Now, with regards to your question, my preference would be a single
> release, as it'd obviously mean less work than having to split commits.
> Also a lot of the UDF "improvements" are actually bug fixes for LFS or
> MinGW, which are supposed to be already at least partially supported with
> LFS fixes also applying to ISO9660.
> It's very possible that if we try to have a first release that fixes as
> many issues as it can, there might actually not be much content left for
> the subsequent release...
> Regards,
> /Pete
> [1]**gitweb/?p=libcdio.git;a=**commitdiff;h=*
> *3831cc250f4319d51a106d263c1fdc**52c5dfda1b<;a=commitdiff;h=3831cc250f4319d51a106d263c1fdc52c5dfda1b>
> [2]**gitweb/?p=libcdio.git;a=**commitdiff;h=*
> *a77c6273f6e7df153b5efc8fee7708**092fa71af5<;a=commitdiff;h=a77c6273f6e7df153b5efc8fee7708092fa71af5>
> [3]**gitweb/?p=libcdio.git;a=**commitdiff;h=*
> *15b97d9a32c34686b201c2e582bb4b**cdc21e00b8<;a=commitdiff;h=15b97d9a32c34686b201c2e582bb4bcdc21e00b8>
Since no other comments, looks like we'll go for one release with
everything. Thanks for commenting.

reply via email to

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