[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible
Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB
Sun, 8 Jul 2018 13:37:18 -0400
Ok. Anyone else like to register an opinion?
On Sun, Jul 8, 2018 at 10:22 AM, Pete Batard <address@hidden> wrote:
> On 2018.07.08 14:52, Rocky Bernstein wrote:
>> I hope I am reiterating something that is consistent with consensus
>> opinion: the next release we go with the compatible ABI and Thomas'
> Well, I guess I wasn't clear enough then, as I disagree with this approach.
> My vote is to *NOT* apply any multiextent changes until we are in the
> process of preparing a new major release, and then go for the much simpler
> ABI-breaking proposal (i.e. ditch Thomas' latest proposal and use mine
> instead, albeit possibly with Thomas' dynamic allocation changes, which I
> don't feel are warranted, as I tried to explain earlier, but that I don't
> see much harm in having if we really believe that people are going to use
> super large multiextent ISO-9660 on systems where they can't use anything
> but shared libcdio libraries).
> In my view, Thomas' proposal is way too disruptive for both libcdio and
> its users, whereas, if we simply decide to wait until we feel that we have
> a good window for an ABI change, we can get something a lot less painful
> for everybody. I have a very strong feeling that, if we decide to go with
> integrating Thomas' latest proposal, it will come to bite both us and our
> users, and the cost/benefit ratio will not be in anyone's favour.
> So my current vote is against integrating these changes, and instead go
> with the much simpler and therefore a lot less disruptive earlier proposal,
> that requires an ABI upgrade, even if that means _waiting_ months or years
> until we feel that the time is ripe to apply these changes.
> But again, that is just my vote. If there is a majority leaning the other
> way, I am certainly not going to oppose the integration of Thomas' latest