Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Date: Mon, 26 Jun 2000 10:58:12 -0400
Message-Id: <200006261458.KAA11672@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: earnie_boyd AT yahoo DOT com
CC: cygwin-developers AT sourceware DOT cygnus DOT com
In-reply-to: <20000626003445.27880.qmail@web108.yahoomail.com> (message from
	Earnie Boyd on Sun, 25 Jun 2000 17:34:45 -0700 (PDT))
Subject: Re: Introducing slight binary incompatibility in newer executables?
References:  <20000626003445 DOT 27880 DOT qmail AT web108 DOT yahoomail DOT com>


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