Mail Archives: cygwin-developers/2000/05/22/21:50:49
> 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.
- Raw text -