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? -> [EMAIL PROTECTED] Cygwin Co-Project Leader [EMAIL PROTECTED] 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/
