> 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

Reply via email to