I want to make a 2.1 FG release, at the end of this month, or the very start of June.
As far as I can see, the current code is pretty good - many bugs have been fixed since 2.0, and while I'm sure some new ones have crept in, I don't have many code quality concerns - if we were to cut tarballs from the source code today, we'd definitely be in a better place than 2.0 in terms of bugs. (If people know of regressions from 2.0, or regressions in 2.0 from 1.9.x, I hope they would mention them here, or even in the bugtracker) Anyway, the key thing - what are the steps to make a release happen. I'm seeking to capture the actual steps (and ideally script them), so even if Curt & Durk both get hit by the proverbial bus tomorrow, we can still make a Flightgear release ever again. But also, I'm seeking to remove the human factors from the release process, and especially not feel that we're overloading people just because a release needs to happen - eg, around LinuxTag Durk is often quite busy organising things :) My build system ( http://zakalawe.ath.cx:8080/ ) is working well for Mac and Linux - MinGW is giving me some pain, I will look into cross-compiling mingw this weekend. If anyone wants to volunteer some time, a Windows box with Visual Studio, some disk space, and bandwidth, I am happy to work with them to get an automated VS build going. Adding more automated steps, even ones which only happen for 'special' builds (eg, a release candidate) is extremely trivial. Regards, James ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
