Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Brian Dessent <brian@dessent.net>]

Corinna Vinschen wrote:

> Sorry, but I didn't remember that.  Why didn't you just tell us?

I thought we were talking about two different things.

As I see it, here are the *conceptual* things we're dealing with:

A) We want to have a tree of packages that is still usable for users of
9x/ME after 1.7 is released, even if it's not updated often or at all. 
Since setup can determine this at runtime, it can simply decide to fetch
a different .ini.

B) We want to have a playground where maintainers and advanced users can
try out 1.7 and packages built against 1.7, in preparation for the
release.

C) During that prep period (i.e. right now) we want the "standard" 1.5
tree to remain and be the default for users.

Now, having written that it appears that (A) and (C) are really the same
thing.  So maybe we only actually have two things: the current tree
which will get renamed to _legacy after 1.7 is released, and a new
playground which will be promoted to the standard "release" tree when
1.7 is ready and tested.

> How do you differ the setup.ini files if you only have different release
> subdirs?  setup_legacy.ini?

Sorry, I actually misremembered how this was implemented.  The switching
happens at the .ini level:

#define SETUP_INI_FILENAME (IsWindowsNT () ? "setup.ini" :
"setup_legacy.ini")
#define SETUP_BZ2_FILENAME (IsWindowsNT () ? "setup.bz2" :
"setup_legacy.bz2")

And of course the .ini file contains the filename of the package
including the "release" part:

version: 1.5.25-11
install: release/cygwin/cygwin-1.5.25-11.tar.bz2 1427217
e1f969931a1e18855716f2c57c3a876a

Thus, setup just looks for a different .ini, the thing on sourceware
that generates that ini can decide what the dirs are named.

> When I came up with that a couple of days ago, I thought it might be bad
> to rename the current release area for 1.5 so that it keeps working as
> is and downloading from the 1.7 release area requires to make the
> conscience choice to use the 1.7 setup.  If we can do this with a
> release-1.7 plus a setup-1.7.ini file, than that's ok for me, too.

So it appears this is what we want:

For right now/temporary:

 - "standard" setup.exe grabs setup.ini/bz2 for both 9x/ME and NT (i.e.
no version checking code)
 - "advanced user/maintainer" setup.exe grabs setup-1.7.ini/bz2
unconditionally which will be a new tree we create, which contains
packages built against 1.7

At point of 1.7 release:

 - rename setup.ini to setup_legazy.ini
 - rename setup-1.7.init to setup.ini
 - release new setup.exe that replaces both of the above, with 9x/ME
check enabled (back to one version of setup.exe)

Sound about right?

And yes, it's rather trivial to release a new setup.exe with the ini
name tweaked, so once we decide on that I can upload such to the
website.

Brian