This is the mail archive of the cygwin 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: Request for a version/ revision/ release number for the whole cygwin release/ distribution


On Thu, Sep 30, 2004 at 10:31:26PM -0700, David Christensen wrote:
>cygwin blah..

http://cygwin.com/acronyms/#PCYMTNQREAIYR

>Per the Cygwin FAQ (http://cygwin.com/faq.html):

>"If you are looking for the version number for the whole Cygwin
>release, there is none.  Each package in the Cygwin release has its own
>version.  The packages in Cygwin are continually improving, thanks to
>the efforts of net volunteers who maintain the Cygwin binary ports.
>Each package has its own version numbers and its own release process.
>"
>
>I would like to request that this policy be reversed -- that there be a
>version number for the entire Cygwin release.  Every O/S and
>application I've used had a release number for the whole thing; Cygwin
>should as well.
>
>I would especially like to request that there be a "stable"
>distribution.

As others have pointed out, this has come up before.  Here's one
discussion:

http://cygwin.com/ml/cygwin/2003-04/msg01449.html

My offer to set up space on sourceware.org (aka sources.redhat.com aka
cygwin.com) and establish a mailing list or mailing lists still holds.
We could add a "stable release" tag to the main web page, too.  All that
we need is someone to maintain this beast.

To reiterate what I said in the above thread, I'm, personally, not
interested in undertaking this kind of release effort, especially given
the limited number of cygwin package maintainers, all of whom have day
jobs.  I'm even less inclined now than I was before since I watched the
pain of getting Fedora releases out the door when I was at Red Hat.

The last time this came up, some people were going to attempt this but
the effort seemed to vanish almost immediately.  However, if there is
now again more interest, then I'll again repeat the offer.  Please
don't underestimate the amount of work involved, however.

I do understand why people would want someone to produce a stable
release in which all packages have been tested.  However, even given
that, there will always be problems.  Having been involved in Red Hat's
RHEL support, I know that a monolithic release is not a panacea.

>1.  I use Cygwin for all sorts of stuff, including mission-critical
>backup chores.  I was recently bitten by the cron-2.6.2 EOF issue, as
>were others.  This represents real damages that people are suffering by
>using Cygwin.  This is bad for the open-source movement.

This assumes that somehow the cron-2.6.2 EOF issue (I'm not familiar
with this and don't recall seeing it mentioned here) would have been
caught in final testing.  You can't make that assumption.  It's entirely
possible that problems like this could slip into a mega distribution.
(Again, I speak from experience)

Given that this is possible, what would you then suggest for a release
policy?  Should we release all of cygwin again to fix the cron EOF
problem?  Or should we release a "hot fix" just for cron?

If we are going to be releasing a major release then we can't do it
quickly, so you suffer as someone runs through complete integration
testing.  If we are going to be releasing "hot fixes" then that's not
very different from the way things are handled now.

I think your best bet is to follow Dave Korn's advice and generate a
stable release that is right for your own situation.  Use that and only
uprade intelligently, i.e., follow the cygwin list to look for trends
or problems before deciding to run 'setup.exe'.
--
Christopher Faylor			spammer? ->	aaaspam@sourceware.org
Cygwin Co-Project Leader				aaaspam@duffek.com
TimeSys, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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