Buchanan, Stuart wrote:
--- Vassilii Khachaturov <> wrote:
What about labelling the fg tree with your own 1.0 pre-release label?
And branching off it, only merging in the trunk changes
that you see fit?
I think this might result in the v1.0 release "withering on the branch" so
to speak ;). Everyone would probably just continue adding new feature to
the non-v1.0 branch, and the v1.0 branch would end up being 0.9.9 and a
couple of small patches.
Not accepting new enhancements until after v1.0 encourages us to fix bugs,
improve docs, generalize features (e.g. the Nimitz changes) etc.
Trying to get a rock solid 1.0 release is a good idea. As it's somethink
like the first big release for the general public, it doesn't have to
have every feature you could think of (there has to be room for
improvement, after all ;))
But the question is: what is a bug, and what is a feature that can wait?
For example I'd strongly consider the missing options saving a bug that
has to be fixed before we give FlightGear to all the people out there.
They are used to this behavior from nearly every program they use, and
will expect the same from FG. Others may think, that we lived without
this feature (who doesn't have his own private preferences.xml in the
search path?) and it would be too an intrusive change. But that's the
difference between a developer and an end user release.
Nine
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
