Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm list-help: list-post: Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-apps AT sourceware DOT cygnus DOT com From: Chris Faylor Date: Mon, 3 Jul 2000 12:59:17 -0400 To: cygwin-developer AT sourceware DOT cygnus DOT com, cygwin-apps AT sourceware DOT cygnus DOT com Subject: Re: Time for something other than cygwin/latest ???? Message-ID: <20000703125917.D27379@cygnus.com> Reply-To: cygwin-developers AT sourceware DOT cygnus DOT com Mail-Followup-To: cygwin-developer AT sourceware DOT cygnus DOT com, cygwin-apps AT sourceware DOT cygnus DOT com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from Michael.Ring@T-Mobil.de on Mon, Jul 03, 2000 at 09:39:03AM +0200 On Mon, Jul 03, 2000 at 09:39:03AM +0200, Michael Ring wrote: >Version 1.1.0 was o.k. but not perfect >1.1.1 was much worse than 1.1.0, some applications refused to run >1.1.2 seems to work fine; Problems in 1.1.1 resolved automagically >(But directory structure changed heavily) What directory structure changed heavily between 1.1.1 and 1.1.2? What applications "refused to run"? 1.1.1 actually fixed a lot of problems that were in 1.1.0. The only problem with it, that I am aware of, was the binmode/textmode stuff. 1.1.3 has Corinna's fixes to avoid accessing the network, which should speed up things for some people. That's why we're trying to get it released. >Applications also changed in a rapid fashion (gdb, ash, inetutils) and >created huge traffic in the cygwin list. (But yes, they got better >from release to release) > >Binary incompatibility creates a new problem: The "binary incompatibility" that has been introduced is no different than what we have done before. Newer versions of cygwin1.dll will still work with older binaries. If it is a tremendously huge deal, I can "fix" the library code to make it backwards compatible. I usually tend to adopt a "wait and see" attitude for this kind of thing, though. It may be a big non-issue. >(Hypothetic) example: > >Someone is happy with cygwin, the way it is now (I could understand >this, works great for me at the moment) >gdb gets updated based on the new (incompatible) library. The only >chance to get it is to upgrade to 'latest'. > >Upgrading to latest solves the gdb problem but introduces a new >problem in another application, he got during the update to latest. >Good for the user if he has a backup of the old version, bad if not >because then there is no way back. The older versions of packages are always available in the "old" directory. >So here's the idea (not new, saw it on the list before): > >Create a new cygwin dll based on 1.1.2 (or whatever is good for the >purpose) and name it 1.2.0 (like in linux, even numbers at the second >position in version declare a version stable) and move cygwin + apps >to that folder. > >Continue development with 1.3.0. (As latest) >I know, this means branching in cvs, but I think it is the better >solution. > >Perhaps there are also volunteers out there in Internet that are >willing to support the stable release so that the cygwin core team can >concentrate on developing new features. Upgraded applications could be >built against the stable codebase once they are prooven to be stable. It is a colossal, large asteroid sized wish that there will be volunteers available to do this. We have only about four people actively contributing anything to the cygwin DLL right now. DJ, Corinna, and I already have to worry about various Cygwin releases in our full-time jobs. I doubt that any of us wants to add something like a "stable" branch to the mix. If this change to libcygwin.a causes massive heartache on the cygwin mailing list, I will fix it. I don't want to muddy the waters with a "supported" and "experimental" branch three months after the release of 1.1.x. We're still fine tuning how we are doing things. I'm trying to make up for the time that we lost during the relatively static B20.1 period. Eventually things will either settle down or someone will implement the site that you're talking about. I doubt that DJ, Corinna, or I will be the ones setting it up, though. cgf