1.7.1 release date?

Corinna Vinschen corinna-cygwin@cygwin.com
Tue Dec 8 13:14:00 GMT 2009

On Dec  8 08:00, Charles Wilson wrote:
> Corinna wrote:
> > cgf wrote:
> >> I was talking about not changing the directory name for a non-beta
> >> release.
> >
> > Sorry, but I don't understand this.  You proposed that the directory
> > gets renamed from release-2 to release, which would collide with the
> > old release directory name.  How is that talking about "not" renaming
> > a directory?!?
> Oh, I get it -- finally.
> The current non-beta release, 1.5.25, lives in release/
> cgf sez the next non-beta release, 1.7.1, should live in release/ (it
> doesn't matter where it lives NOW; it's currently in beta so that
> location doesn't "count").
> Thus, the non-beta "home" should continue to be "release/" -- e.g., no
> "renaming".
> If we didn't care about legacy users, that would be the end of it.  We'd
> simply do a mass copy of everything in release-2/ over to release/, and
> rm -rf release-2.  Since we DO care (a little bit) about legacy users,
> we first "copy" the current contents of release/ over to
> release-legacy/.  (The actual mechanics of this: breaking the union
> mount, and simply doing directory level renames, is an implementation
> detail).
> IIUC, that's cgf's position, and with the definitions above, it is
> consistent with everything he's stated in this thread so far.
> ====
> The biggest concern raised so far, that this plan doesn't address, is
> what happens to poor schlubs running *current* (that is, old 1.5ish)
> setup.exe cached on their machine [*]?
> Answer: nothing [**].  You only get upgraded to 1.7 if you download the
> new setup.exe.
> [*] This is not an uncommon use case. /I/ never run anything directly
> from the web.  Hell, I never download and run anything -- not even
> cygwin's setup.exe -- without first saving it, running a virus scan on
> it, and checking its signature if possible.  So, I use my cached
> setup.exe and let IT tell me there's a new version of itself I need to
> download.
> [**] IF current (that is, old 1.5) setup[-legacy].exe continues to "own"
> the setup.ini file, and the new (that is, 1.7) setup[-1.7].exe continues
> to use setup-2.ini.
> Where we get into trouble is if we start reassigning who gets to use
> 'setup.ini'.  So, assuming for the sake of argument that we do NOT
> reassign that, and [**] continues to hold.
> In that case, we will have the following under cgf's plan (ignoring
> certain hardlinks for backcompat purposes, and bz2 compression):
> release-legacy/   <--> [setup.ini AND     <-->  setup-legacy.exe
>                         setup-legacy.ini]
> release/          <-->  setup-2.ini       <-->  setup.exe
> This seems confusing to me -- unsymmetric, if you will -- which is why I
> proposed
> amphibius/   <-->  setup-amphibius.ini [***]  <-->  setup-amphibius.exe
> kiboko/      <-->  setup-kiboko.ini           <-->  setup-kiboko.exe
> or
> release-1/   <-->  setup-1.ini [***] <-->  setup-1.exe
> release-2/   <-->  setup-2.ini       <-->  setup-2.exe
> [***] plus a setup.ini hardlink, for cached-old-setup.exe users.
> But it is, after all, an implementation detail.  bikeshedding, if you
> will.  I won't press for any one solution, here.  BUT, I will strongly
> urge AGAINST the following:
> release-legacy/   <-->  setup-legacy.ini    <-->  setup-legacy.exe
> release/          <-->  setup.ini           <-->  setup.exe
>                              ^----- oh noes!
> because THAT will end badly for Win9xME users, who use a cached
> setup.exe like I do.  Unfortunately, following my suggesting -- to
> protect these users -- effectively means that *no one*, not even WinNT+
> users -- will be automatically upgraded to cygwin-1.7, unless they
> download a new copy of setup.exe.
> Is that a bug, or a feature?

Feature, IMHO.  The upgrade from 1.5 to 1.7 is too big to go along
without users having to take notice.  They have to adapt consciously
and they have to read and perhaps even understand the new User's Guide.
My local change to index.html adds a note in a very prominent place to
help those who just start setup.exe via cygwin.com.  But a change to
setup.exe as well is probably the better way.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list