1.7.1 release date?

Dave Korn dave.korn.cygwin@googlemail.com
Sat Dec 5 17:33:00 GMT 2009

Charles Wilson wrote:
> 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...

  Well, we _could_ do that.

  Or we could use "release" for the first release, "release-2" for the second
release, "release-3" for the third release, "release-4" for the fourth
release, and so on.

  I think that kind of wins on any definition of simplicity, maintainability,
forward- and backward- compatibility, lack of churn, obviousness of which one
is most recent - in fact, pretty much every factor I can think of, with the
sole exception of "number of directories named after species of hippo"!


More information about the Cygwin-developers mailing list