This is the mail archive of the
cygwin-developers@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: Introducing slight binary incompatibility in newer executables?
- To: cygwin-developers at sourceware dot cygnus dot com
- Subject: Re: Introducing slight binary incompatibility in newer executables?
- From: Chris Faylor <cgf at cygnus dot com>
- Date: Mon, 26 Jun 2000 12:02:08 -0400
- References: <20000626153743.15312.qmail@web115.yahoomail.com>
- Reply-To: cygwin-developers at sourceware dot cygnus dot com
On Mon, Jun 26, 2000 at 08:37:43AM -0700, Earnie Boyd wrote:
>--- DJ Delorie <dj@delorie.com> wrote:
>>
>> > IMHO, it is, any cygwin-app that is updated now, will have to have
>> > the updated cygwin1.dll. What other changes are you thinking of?
>>
>> We bump the middle number when the converse is true - when updating
>> the DLL means you *must* update the cygwin apps also.
>>
>> All we're doing with this change is the same thing we've been doing
>> with all our other changes - adding functionality. This means that
>> apps built for the new DLL won't work with older DLLs.
>>
>> If we change or remove functionality, *then* we bump the middle
>> number, because apps build for the old DLL won't work with the new
>> DLL. It's only when backward compatibility is broken do we have to
>> worry about migration.
>
>Ok. But, IMO, we need a 1.1.4 before this modification so that we can take
>advantage of Corinna's patches for the speed issues of ntsec. Then 1.1.5 will
>contain this modification.
The new DLL still handles old binaries so I don't think there is any reason to
hold off.
cgf