This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: 1.7.1 release date?
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: cygwin-developers at cygwin dot com
- Date: Sat, 05 Dec 2009 07:34:51 +0000
- Subject: Re: 1.7.1 release date?
- References: <4B19F3B2.2020205@cwilson.fastmail.fm>
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"!
cheers,
DaveK