Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Date: Wed, 19 Mar 2003 16:19:47 -0500 From: Christopher Faylor To: cygwin-developers AT cygwin DOT com Subject: Bump version to 1.5.0 Message-ID: <20030319211947.GA29068@redhat.com> Reply-To: cygwin-developers AT cygwin DOT com Mail-Followup-To: cygwin-developers AT cygwin DOT com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i Corinna has suggested to me that maybe we should be bumping the cygwin version to 1.5.0 given the 64 bit changes and my upcoming device handling and mount table changes. I'm thinking that we might need a few more 1.3.x releases before 1.5.x is stable so *maybe* I could keep 1.5.x cygwin releases in the "test" category for a while and keep releasing 1.3.x until things settle down there. It may be that there will be no need for further 1.3.x versions but I had sort of hoped to have a gold version of 1.3.x ready that people could rely on before we started really destabilizing things for 1.5.x. I know that we'd talked about changing to version 2 of cygwin, too, but that is going to be a pretty daunting task. It means someone amongst us would have to write a cygwin1 wrapper DLL so as to not leave the old cygwin1 users behind. It ideally means rebuilding the whole distribution with cygwin2 libraries. It means stripping out all of the legacy code in cygwin1.dll (rewarding as that would be). So, I think we can stick with 1.5.x for the conceivable future. Of course, to get the full benefit of the 64 bit stuff, maintainers will have to start rebuilding with the 64 bit version of the dll, too, so part of the above is inevitable anyway. And, as soon as someone rebuilds their app with 1.5.x, it will no longer be backwards compatible with 1.3.x. Maybe that means that 1.5.x should be released sooner rather than later. Head hurts. Another idea I had was to throw out the "odd releases net, even releases Red Hat" versioning that DJ and I came up with so long ago and just bump the version to 1.9.0, working for the eventual transition to a cygwin2.dll. When we feel comfortable that everything is ready (dll wrapper, legacy code stripped) then we roll the version to 2.0.0 and then start actively rebuilding everything for the new DLL. Anyway, I'm leaning towards a 1.5.0 bump soon but I reserve the right to go with the 1.9.0 too, at some point. cgf