On Fri, Oct 01, 2004 at 11:52:15AM -0500, Fred Kulack wrote: >On 10/01/2004 at 12:31:34 AM, cygwin-owner wrote: >Every O/S and application I've used had a release number for the whole >thing; Cygwin should as well. >--- end of excerpt --- > >At a minimum, I think that's quite an oversimplification and perhaps >factually untrue? > >Have you used a Linux distribution for example? There's a single >release number, but its really rather meaningless, because the first >thing you do is install updates to various packages (possibly including >the kernel). > >That's very similar to cygwin. You have a base version of the cygwin >DLL, and version number for each package. I suspect that the best >you'll have is to explicitly test and ship your product with a specific >version of the packages that you use.
Yeah, I've always thought of the way that Cygwin does things as more of a feature than a bug. Cygwin's current policies do put the onus on the end user to figure out what's best for their use, but, really, that is true of any large software release. It's probably a lot more obvious with cygwin. As I said, I very am familiar with the effort that goes into releasing Red Hat's Enterprise Linux product and I'm somewhat familiar with the Fedora Project. I think that the Fedora project is closer to what is being requested for Cygwin. Unlike Cygwin, for Red Hat Fedora or RHEL, you don't normally run 'up2date', 'yum update', apt get, or whatever to pull down the next *major* version of emacs. You only get security errata or fixes for serious bugs. That's nice if that's all that you care about but it means that there are programmers somewhere who are noticing security problems and backporting fixes from the newest versions of emacs into the older versions that shipped with the "stable" release. That's a job that no one enjoys. I don't think we have any volunteers here for that. Another problem with Fedora and RHEL is that updating to the next major release isn't always supported without wiping out your installation and reinstalling. This is because it is very hard to track dependencies in everything that has changed in the course of development. "Little" things like switching from XFree86 to Xorg or using udev instead of devfs can cause problems in unanticipated ways, creating support headaches. If we did start releasing Cygwin in this way then we might have similar problems since people will not be updating incrementally and we would not be seeing problems when they occur. Instead we'd be seeing problems months after we made a change. Fedora has various flavors of development and testing repositories that you can connect to if you want to get the latest and greatest, so you can satisfy the cravings to always be on the cutting edge. Unfortunately Fedora has a much more technically active user base than cygwin does. Fedora is a much sexier "product" than Cygwin. This is illustrated, IMO, by the fact that the traffic on the Fedora lists dwarfs the cygwin lists. That means that there might be a couple of people working on emacs and there will be many more people testing things to make sure that they are stable. I don't think it is inconceivable that some kind of similar activities could spring up around cygwin, on a smaller scale. Maybe all that it would take are one or two people willing to spend a lot of effort in generating stable releases. Then the current cygwin release would just be a "development" channel for the stable release. While it's not inconceivable, I don't think it is very likely, though, and I think past conversations on the cygwin list show this. -- 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/
