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, 22 May 2000 21:50:33 -0400
Message-Id: <200005230150.VAA00356@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: cygwin-developers AT sourceware DOT cygnus DOT com
In-reply-to: <20000522213648.A15412@cygnus.com> (message from Chris Faylor on
	Mon, 22 May 2000 21:36:48 -0400)
Subject: Re: Next net release will be 1.1.3
References: <20000522172249 DOT A10159 AT cygnus DOT com> <200005222150 DOT RAA31092 AT envy DOT delorie DOT com> <20000522191937 DOT B14279 AT cygnus DOT com> <200005222328 DOT TAA31855 AT envy DOT delorie DOT com> <20000522213648 DOT A15412 AT cygnus DOT com>


> I think you forgot an IMO there.

Yeah, well, everything I say is IMO.  I'm very O-ated ;-)

> I can easily envision a user responding that the version is "1.1.1"
> when asked what the version number is above, especially if they know
> that cygwin's version numbers are "always" x.y.z.

Other GNU packages (binutils, gcc) use a non-release version for
snapshots.  We should too.  Snapshots could be x.y.z.s or
"ss-YYYYMMDD".  I hate to think that people using snapshots aren't
smart enough to recognize a different version number style.

> If we could record version numbers in every package we release, I think
> that would be the best way to do all of this update stuff.  So far only
> cygwin stores this info.

We do, in the tarball names.  Sort of, except for the ones from the
CD-ROM that we haven't rebuilt yet.  We really do need to keep track
of the installed tarballs and the files (size/checksum) that came from
that tarball, so we *know* what setup last installed.  Trying to
compensate for a user corrupting an installation by special casing one
of the installable files sounds like it's going to cause problems in
the long run.  A solution that works for *all* tarballs is a better
goal, and we need that anyway.

All setup needs to know is that you're supposed to have version foo of
package bar installed, but you really have version grill, so you must
reinstall.  Setup shouldn't care about newer, older, or version
comparisons.  The only tricky part is figuring out what the version
you're supposed to have installed is, and I think some config file on
the FTP sites (or wherever; I posted a query about that) is the right
way to go, because we may need to regress to an older version if we
discover instabilities.

> No one is talking about tossing version numbers.  That's your
> interpretation.

I meant that the FTP sites would never have odd version numbers.
People who don't know about the snapshots would see 1.1.4, then 1.1.6,
and wonder what happened to 1.1.5.