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?


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?

--
Chuck


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