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?


cgf angrily wrote:
> What we're talking about here is changing the way Cygwin releases are
> done.  We're assuming that we will routinely make major changes which
> break things and cause people grief and so we need to create a directory
> structure allowing the unwashed masses to stay within the bounds of
> various comfortable hippo-based release while the head of Cygwin
> development marches on.
> 
> I know that's what other projects do but this is not what we have
> historically done.  The release-2 directory was supposed to be a
> once-in-a-decade occurrence.  If that is not the case then we need a lot
> more discussion than having people come up with their own variations on
> hippo-related names.

and later sarcastically added:
> Or, we could have a formal discussion about totally changing the Cygwin
> release model and not hide it in a mailing list thread with the subject
> "1.7.1 release date" in a side thread about whimsical directory names.
> The notion of having Cygwin "releases" is something that has to be taken
> up with more than just the people in this mailing list.

Apparently I did not emphasize well enough the extreme *rarity* of these
"new" names -- which are *directory names only* NOT "releases" in any
way. I mentioned "in 15 years" we could worry about running out of these
names -- which translates to about five years between paradigm-breaking
transitions.  cgf says 10 years apiece; but really, we're talking about
the same *extremely* infrequent occurance.

I did NOT mean to imply "changing the way releases are done" -- e.g.
NOTHING like "okay, cygwin-1.9 will be capensis/, 1.11 will be
tschadensis/, and OOPS, we've run out of names already, now what..."  I
mentioned Ubuntu release namings to CONTRAST, not to imply we would do
it thier way; that'd be stupid for us.   Our USUAL update process --
which NORMALLY doesn't require screwy directory renames, nor entirely
new trees every frakking six months -- has served well from 1.1.x to
1.3.x to 1.5.x over six years.  I see no need to change that for
1.7,1,9,1.11, etc 'just because'; ONLY if there is a paradigm-breaking
issue like 1.5->1.7 dropping win9x support, or cygwin1.dll->cygwin2.dll.

So, in my whimsical proposal, I envision kiboko/ in continued use for at
least five, maybe ten solid years, from 1.7.x to 1.9.x to 1.11.x and
beyond...maybe only when 2.0(cygwin2.dll) is released, would we need to
worry about "another" directory name like capensis/.

Frankly, I'd be perfectly happy to just stick with "release" and
"release-2" -- except that the "2" is somewhat offputting, associated as
it is/willbe with  cygwin "1.7" and "1.9" and "1.11" etc (not a "2" in
the bunch). OTOH, doing the cgf magic directory shuffle WILL break
existing users, on win9x, who are using thier current setup.exe.  It
will look for setup.ini (which after the magic shuffle, now contains
references to cygwin-1.7 packages) and will happily install those
packages, because it doesn't know any better.  On their Win9x system.
Breaking it.

I know we're just mean and all, but that goes above and beyond, even for
us.

My proposal was NOT meant to be an attempt to change the cygwin "release
process" (eg. the *normal* cygwin-1.x.y to 1.x+1.0 transitions, unlike
the current paradigm-breaking one) at all. It was merely intended as a
proposal for the new directory names on the mirrors, since we're talking
about renaming them anyway. Why not use whimsical names if we want to,
instead of boring ones like "release-legacy" and "release-2"?  *NOTHING*
else would change; so this is a simple, internal "implementation" detail
perfectly appropriate to be "buried" in the current thread, IMO. 

--
Chuck


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