Mail Archives: cygwin-apps/2002/03/27/12:02:54

Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <>
Date: Wed, 27 Mar 2002 11:56:46 -0500
From: "David A. Cobb" <superbiskit AT cox DOT net>
Organization: CoxNet User
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020322
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: bkeener AT thesoftwaresource DOT com, cygwin-apps AT cygwin DOT com
Subject: Re: prev/curr/test
References: <20020323061924 DOT GA3593 AT redhat DOT com> <VA DOT 00000b0b DOT 01c1b54e AT thesoftwaresource DOT com>

Brian Keener wrote:

>Christopher Faylor wrote:
>>evil and should be abolished.  The only way to get old versions
>>should be at a macro level.  You click a button and get all of
>>the old stuff, you click another button and get all of the current
>>stuff, you click another button to get all of the test stuff.
>>I think that Robert is right that if you click on test you should
>>only get packages that have test versions.  Ditto for prev.  Ditto
>>for curr.
>Sorry guys,
>I still like the idea of keeping Prev,Curr and Test but as a means of limiting 
>the maximum version I want to see - IE if I didn't select Test I won't see any 
>test but I will see prev and Current. 
>Then I suggest we do away with the Source Box and nix the idea of a bin box and 
>simply use the clickable version and within the version we have such entities 
>as the following (assume the version installed is 1.4.3 and there is a current 
>of 1.4.4 and I have curr selected on the radio buttons):
Nah!  I found the source/bin boxes a great addition.  My problem with 
the spinner-only selection was that sometimes I had to run around the 
cycle once to see what versions were available.  

>keep/skip (obviously skip if nothing were installed), uninstall (would only 
>exist if package installed), 1.4.4 bin&src, 1.4.4 bin, 1.4.4 src, reinstall 
>bin&src (would reinstall both for 1.4.3), reinstall bin (reinstall bin for 
>1.4.3), reinstall src (reinstall src for 1.4.3), retrieve bin&src (retrieves 
>installed bin and src), retrieve bin (retrieves installed bin), retrieve src 
>(retrieves installed src), retrieve 1.4.4 bin&src ...
Looks far to complex for me as a simple-minded user

While we're chewing on this, consider an easy (one-click) way to obtain 
all "new" packages; i.e. the one's that are now marked "Skip" and for 
which I have to do a manual hunt now.

Again, a very personal opinion: I would rather simply have Prev(_) 
Curr(_) Test(_) selections for each package.  Normally, I don't much 
care what the revision string is.

>The retrieve options would be available as opposed to the reinstall or install 
>options if we were doing a download only as opposed to an install.  As an added 
>goody as part of the text for each option you add if it is the prev, curr, 
>test, or just on that is available.
>I originally posted this idea in a discussion with Rob on March 5 - but is sort 
>of died with the thread as the message. So I'll try again.  Just an alternate 

David A. Cobb, Software Engineer, Public Access Advocate
"By God's Grace I am a Christian man, by my actions a great sinner." -- The Way of a Pilgrim; R. M. French, tr.
Life is too short to tolerate crappy software.

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019