Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com From: Chris Faylor Date: Mon, 22 May 2000 23:09:01 -0400 To: cygwin-developers AT sourceware DOT cygnus DOT com Subject: Re: Next net release will be 1.1.3 Message-ID: <20000522230901.A15569@cygnus.com> Reply-To: cygwin-developers AT sourceware DOT cygnus DOT com Mail-Followup-To: cygwin-developers AT sourceware DOT cygnus DOT com 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> <200005230150 DOT VAA00356 AT envy DOT delorie DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200005230150.VAA00356@envy.delorie.com>; from dj@delorie.com on Mon, May 22, 2000 at 09:50:33PM -0400 On Mon, May 22, 2000 at 09:50:33PM -0400, DJ Delorie wrote: >> 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. The utsname field that contains the version number will not accommodate another nine characters so 1.1.1.20000522 is not feasible. I don't like a numbering scheme where it isn't obvious if ss-20000522 is newer than 1.1.0. Also, the packages on alpha.gnu.org seem to use all sorts of different version number schemes. I only see a couple that include date. gdb does seem to have a date stamp. The version that I recently built from a fresh sourceware cvs update says "gdb 20000204". The .tar.gz files are named by the snapshot date, of course. It may be that 99% of the people using snapshots will understand that they have to include a string of additional digits when reporting a version number but I was trying to put the focus of understanding on the people supporting the product rather than the people reporting problems. >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. Sure. Put version number strings in all of the .exe's that are installed. Then if tar file A wipes out an executable that was also in tar file B we don't rely on external, erroneous data about tar file A to make update decisions. That's a foolproof if impractical solution. In any event, the only case that really needs special casing is cygwin. One reason that it needs it is that the cygwin-1.1.0 tar file was named cygwin-20000301.tar.gz. The other reason is that people download snapshots and, if things stop working, start moving things around in attempts to get things working again. >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. OK. The regression point is a good one. The current version of setup can't handle anything like this of course. You're talking about control from the download site which would be cool. My goal for the current crude version of setup was to allow a user to type "setup -u" to have all of the packages on his system updated with "newer" versions. Setup doesn't know about versions or dates. It just knows about normalized strings of alphanumeric characters following a "-" and prior to a .tar.gz. It sorts based on those. >>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. I guess I don't see this as a big deal. When I go to download something I always look for the newest thing to download. With our directory layout the only thing a person will see currently is the newest version. They would actually have to remember that the last version was 1.1.4 to wonder what happened to 1.1.5. Basically, I'm trying to make this work well enough so that people can screw up and still recover. There is adequate evidence on the cygwin mailing list that people can screw up their systems royally and be totally confused, so arguments about what people "should know" don't mean much to me. I just want "setup -u cygwin" to do the right thing as much as possible. I don't care as much about "setup -u bash" or "setup -u textutils", at least for now although I think there are fewer problems with people playing with bash.exe than with cygwin1.dll. "Incrementing by two" is something that would work for cygwin now. It doesn't involve another special case in setup.exe and it doesn't require that we trust that the user has set up everything perfectly on their system. I could be wrong but I think that the number of "What happened to cygwin 1.1.5" messages in the mailing list would be much less than the "I think I upgraded to the newest net release but I still have the same problem" messages. As usual, I didn't expect that this would be a controversial topic. I think my next post to this mailing list will be on the subject of puppies and kittens. (Hint: I like them.) cgf