On 11.12.2010 09:16, Durk Talsma wrote: Firstly, what is the next version number going to be. My initial thought would be 2.1.0, but it also makes sense to call if 2.2.0 (thanks for the suggestion, James), so that we can reserve 2.1.0. for bugfixes on the current version, or at least move toward a versioning system like that (i.e. the next series could be 2.2.0 for stable, and 2.3.0. for development).
+1! A scheme which covers stable/unstable (GIT) versions seems a very good idea. Many people are using the GIT version, so it'd be good to have a specific version for such builds. But bugfixes should only affect the third version number then, i.e. a bugfix for the 2.0 stable should be 2.0.1. It sill makes sense to move to 2.2.0 now - stable release versions should be even. Seconly, do we want to maintain our current aircraft selection, or do we want to include a (partially) updated selection from our git repository, or -alternatively- do we want to strip the entire selection down to just single aircraft, and make the others downloadable from our main website. I know that James turner is working towards an infrastructure that should enable this, but I'm not sure whether we are already comfortable enough to just use one single aircraft. The new system allowing multiple aircraft dirs works great. However, it seems not too many people have used it so far. And at some point after the release, we wanted to split FGDATA into several smaller repositories (I know Tim has already been working on this), so we'd be introducing a new system for 2.3 (GIT) / 2.4 (future stable) anyway. So it might be better to stick with the current system for this release and not have another unnecessary intermediate. And we'd get a lot of GIT users testing the new directory and distribution system with 2.3.0 - so that would be rock stable for 2.4. cheers, Thorsten
------------------------------------------------------------------------------ Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev
_______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
