RE: [ANNOUNCEMENT] Server Test 58 [Robert Collins, this one is for you]

["Robert Collins" <robert dot collins at syncretize dot net>]

> -----Original Message-----
> From: cygwin-xfree-owner@cygwin.com 
> [mailto:cygwin-xfree-owner@cygwin.com] On Behalf Of Harold L Hunt
> Sent: Monday, 17 June 2002 6:37 AM

> The primary problem is that to make test releases available 
> via setup.exe I
> need to put a caveat lector (let the reader beware) for 
> setup.exe users in the
> release announcements that would be so huge as to distract 
> attention from the
> test release itself.  The problem, as I see it, is that I 
> need someway to
> version test releases such that I can indicate that one test 
> release is newer
> than other test releases but also so that any given test 
> release is seen as
> older than the latest stable release.  The way I've chosen to 
> do that for now
> is to give the test releases the version number of the *next* 
> stable release. 
> If I release 5 unstable releases between a stable release 
> they will all have
> the same version.

The setup.ini format has two orthogonal parameters describing packages.
One is version number. The other is 'Trust'. Trust is a 3 valued
parameter - prev, curr, test/exp. Marking a package version as test
means it will not be installed by default, it will require the user to
cycle through the version list, or click on 'test' in the setup.exe
chooser to have the package install.

I'd suggest naming test releases like this:
If current is 4.2.0-6 then
Test could be 4.2.0-6Test1
Test could be 4.2.0-6Test2
Test could be 4.2.0-6Test3
Or even 4.2.0-6Test59
And the next release is 4.2.0-7

As long as the filenames and version numbers never equate, setup will do
the right thing. And the Test marking will be obvious.
 
> What is a user to do? Any user that messes with installing 
> Server Test Series
> releases via Cygwin's setup.exe must uninstall their 
> XFree86-xserv package
> before attempting to grab the latest Server Test Series 
> release or any new
> stable release.  Why?  Because setup.exe doesn't know that a 
> package with
> version 4.2.0-6 with date 2002-06-13 is older than the next 
> Server Test Series
> (or stable) release 4.2.0-6 with date 2002-06-14.

Setup cannot discriminate between packages with the exact same version
number. Users will not need to uninstall their current package with what
I'm suggesting - setup will do that automatically.
 
> The behavior that I want from Cygwin's setup.exe, if it isn't 
> already present
> and clearly documented, is as such:
> 
> 1) Allow a different versioning scheme for the `test:' tag in 
> setup.hint than
> the `curr:' tag (i.e., allow a test versioning scheme of 
> 20020613-2245 for
> test and 4.2.0-6 for 'curr'.

Already done. The schemes have to obey a very small policy, which both
of the above do.
 
> 2) Allow some way to indicate that the latest stable release 
> supersedes all
> test releases up to a certain version.  Alternatively, the 
> test version could
> be 4.2.0-6-test-20020613-2245 (or something similar, whatever 
> you need to make
> parsing easy and to retain compatibility with other 
> versioning schemes).

Do my suggested version numbers above meet this criteria for you?
 
> 3) When setup.exe sees that 4.2.0-6 stable is available it 
> installs 4.2.0-6
> stable overtop of whatever test release is installed (if the 
> user allows the
> upgrade).

Hmm, not sure on this one. You should create a trivial setup.ini file
and test locally. This becomes a matter of policy for the cygwin-apps
list. I *think* that the current behaviour is this, or very close
anyway.
 
> Hmm... maybe I just have to use both the `curr:' and the 
> `test:' tag in
> setup.hint and update them every time?

You will need to do that to get the correct info in setup.ini.
 
> One last question then: does setup.exe *ever* try to upgrade 
> a test release to
> a stable release?  Or does setup.exe just assume that any user who has
> installed a test release has taken the responsibility upon 
> themselves as to
> when they should upgrade to the newest stable release?

It treats the test release as a user decision, but will default on all
changes to go back to current - unless the user chooses to stay on test.
I.e. it'll downgrade to stable by default. Again, this is from memory, I
don't recall the exact decision that was reached in cygapps. It can, of
course, be reviewed and discussed.

Rob