This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.7.1 release date?


Brendan Conoboy wrote:
> Since you're already on the verge of a great release that will 
> require some site changes, why not take full advantage? Why not come 
> up with a codename that represents all the new 1.7 functionality and 
> use that for a directory name? The OpenWRT project, for instance, is 
> doing development on 'kamikaze' while 'whiterussian' is the previous 
> major release milestone. If people have ever wanted to alter how 
> Cygwin development and releases work, like a stable-vs-devel system,
> implementing that as part of the rename seems like the right time to
> do it.

Maybe the following would work, as a transition scheme. It's a bit
complex, but I think it avoids most of the problems folks have mentioned.

1) current setup.ini continues to be associated with setup[-legacy].exe

2) current setup-2.ini continues to be associated with setup-1.7.exe,
even after setup-1.7.exe is renamed to setup.exe.

HOWEVER, the directory structure gets changed as follows:

release/    -> amphibius/
release-2/  -> kiboko/

These names are taken from the five sub-species of hippopotamus:

    * H. a. amphibius (H. a. stands for "Hippopotamus amphibius", so
                       this version has amphibius in its name twice)
    * H. a. kiboko
    * H. a. capensis
    * H. a. tschadensis
    * H. a. constrictus

upset is modified to generate "setup-kiboko.ini", and create a hardlink
setup-2.ini.

One last time, upset is run on the release/ (ne' amphibius/) directory,
to generate setup-amphibius.ini and a hardlink setup.ini with
appropriate paths inside amphibius/.

"old" setup is called "setup-amphibius.exe" (with perhap hardlinks named
"setup-legacy.exe" and "setup-win9xMe.exe") This newly compiled version
of the old setup codebase would by default look for setup-amphibius.ini.
 setup.ini is kept around only for those people that are using a
previously-downloaded copy of old setup.exe.

"new" setup is called "setup-kiboko.exe" (with perhaps a hardlink called
"setup.exe").  This newly compiled exe by default will look for
setup-kiboku.ini.  setup-2.ini is kept around only for those people that
are using a previously-downloaded copy of "new" setup-1.7.exe.

There exist, at the top level cygwin/ directory, the following (empty)
files:

__CYGWIN_kiboko_is_CURRENT
__CYGWIN_amphibius_is_win9xMe_only_UNSUPPORTED


Note that in this scheme, kiboko would not simply be "1.7" by another
name. It would also be 1.9.x, 1.11.x, up until we hit another SUPERMAJOR
milestone (similar in magnitude to dropping support for an entire class
of Windows operating systems, or the cygwin2.dll transition).


The benefits of this scheme:

1) people using the copies of setup.exe and setup-1.7.exe sitting on
their harddrives right now, can continue to use them without surprises

2) We avoid any confusion associated with "release-2" being current, but
"release" being completely unmaintained, but with a name that implies
active support.

3) Hippo names are cool.

4) It's extensible for later SUPERMAJOR milestones. In 15 years, we can
worry about what comes after constrictus.

Downside:

1) Just as much mirror churn as the release-2/release <->
release/release-legacy swap.  I'm not really convinced this is a
terrible penalty.

2) Folks might think that "kiboko" is a true "cygwin release" in the way
Jaunty Jackalope or Feisty Fawn is.  In CVS terms, it's not a "tag" it's
a "branch" -- a continuing line of development distinct from those that
preceded it.

3) Nothing intuitively says "amphibius" is old busted, "kiboko" is new
hotness -- except the empty files I mentioned above, and perhaps text on
a webpage somewhere...

--
Chuck


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]