X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Thu, 11 Dec 2008 10:17:18 +0100 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: Public Cygwin 1.7 test starts today Message-ID: <20081211091718.GE15192@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20081210203400 DOT GA15192 AT calimero DOT vinschen DOT de> <494061C2 DOT 9070306 AT etr-usa DOT com> <20081211025042 DOT GA3571 AT ednor DOT casa DOT cgf DOT cx> <494092AE DOT 6060902 AT etr-usa DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <494092AE.6060902@etr-usa.com> User-Agent: Mutt/1.5.16 (2007-06-09) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Dec 10 21:10, Warren Young wrote: > Christopher Faylor wrote: >> On Wed, Dec 10, 2008 at 05:41:38PM -0700, Warren Young wrote: >>> Is this going to change for the next major release? There's an awful lot >>> to absorb in this one. >> If you mean for 1.9.x then there is no way to predict that. > > I was just asking about intentions. Do the core developers *want* to pile > up new features and breakages over a period of many years and release them > in a huge batch, or do you prefer to release smaller batches more often? The really big move to 1.7 is done. In the next time the changes will be more iterative again, if that's what you're asking. >> It's possible that the next major release will introduce cygwin2.dll. >> That >> would be a long time coming. > > Do you have a sense for what would make the next major release cygwin2.dll > and not cygwin1.dll? Obviously an API or ABI breakage would require a new > DLL name, but do you have something on the wish list that would require > that, which was put off this time around? Windows will run under Cygwin 2.0 instead of vice versa. > What I was really asking is about execution time. Does it run faster with > all those if (win9x()) { ... } else { ... } logic forks removed? Or > conversely, perhaps there's new completeness or correctness code that slows > some things down? Certain File I/O should be faster (directory listings for instance), but other than that, we made no performance tests. Some changes were meant to make Cygwin perform better, some other to make Cygwin behave more correct. Sometimes these development goals collide. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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/