> BTW, "feature freeze" is meant to be exactly this: No addition of new > features. There's no point in delaying feature freeze specifically for > aircraft as the feature set of the core, which aircraft are supposed to > run on top of, is already supposed to be stable by definition of the > feature freeze.
Doesn't make sense to me (I have no clue what you mean). Theoretical situation: Somebody commits a major change of JSBSim one day before feature freeze. Shouldn't be a problem as such, because just before feature freeze the repository is open. Next day, feature freeze is in place, but it turns out several JSBSim aircraft don't run. Shouldn't be a problem, because you can still commit fixes. But: developer X has been working on his JSBSim aircraft and wants to commit it (for the first time) just in time one day before feature freeze - however discovers on that day that his aircraft doesn't run fly more (see above). That is a problem, because he either commits a broken aircraft in the hope to be able to fix it later, or he misses the deadline. Aircraft (and partially Nasal) are things dependent on the core - so naturally they can only be designed with respect to a given core state - and that means that conceptually the core has to be fix before the dependent stuff is fixed. At least that's how it makes sense to me... Cheers, * Thorsten ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
