Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps AT cygwin DOT com Delivered-To: mailing list cygwin-apps AT cygwin DOT com Message-ID: <3CA1F9CE.2090104@cox.net> Date: Wed, 27 Mar 2002 11:56:46 -0500 From: "David A. Cobb" 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> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 >thought. > >bk > > > -- 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. .