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 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? ->
Cygwin Co-Project Leader
TimeSys, Inc.

Unsubscribe info:
Problem reports:

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