Hi there,
I'm very happy that we finally released 1.9.0.
According to the discussions before the release, I believe that many of us are
willing to release FlightGear more often, like semiannually or quarterly (or
even more often). To release more than once a year, I believe that we need to
have clearer roadmap, versioning policy, and the release process.
Here are my opinions so please give me comments and feedback please.
1) The version numbers and release dates
Here's an example list of version numbers and release dates when FlightGear
will be released quarterly.
2.0 - at the end of March, 2009
2.1 - at the end of June, 2009
2.2 - at the end of September, 2009
2.3 - at the end of December, 2009
0.1 is increased on every release until it reaches the goal of 3.0.0 (it can be
2.10.0 or 2.150.0 :-p)
I think incrementing minor version number on each release is enough for our
project, and micro version number can be reserved for bug-fix releases between
two releases.
2) Milestones (Goal for each release)
Here's an example list of "must-achieve" things for 2.0.0 (based on discussion
on the list, I believe).
[2.0.0 - at the end of March, 2009]
Functionality:
- Landing Lights
- Shadows
- More improvements in 3D clouds (I don't know the exact goal on this
though...)
Reliability:
- NaN things must be eliminated
- SIGSEGV must be avoided when:
+ no osg plugins are found
+ a sound file is missing
+ there are some other missing xml / ac files
Usability:
- to be determined (T.B.D.)
Effifiency:
- T.B.D.
Maintainability:
- T.B.D.
Portability:
- T.B.D.
[2.1.0 and further versions ]
- T.B.D. :-p
We can add more items on each category (I took these categories from ISO-9126,
but we can express the must-achieve things in a different categorization) Maybe
we need to separate general FG things from per aircraft things.
It is also very good to organize the must-achieve items for each release based
on the following documents:
- http://wiki.flightgear.org/index.php/Long_Term_Goals
- http://wiki.flightgear.org/index.php/FGFS_Todo
- http://wiki.flightgear.org/index.php/Feature_Requests_/_Proposals_/_Ideas
I believe that these milestones don't prevent the developers from implementing
their new ideas at all.
we can freely add new features even these are not listed in the milestones.
Moreover, if we cannot implement some of the must-achieve items due to lack of
time, then we will carry these over the next release, and make the current
release published.
3) Release branch
I believe that we need to have a release branch for both developers and release
organizers.
The main reason is to separate bug fixes from implementing a new features. This
way, developers don't have to wait for the release
to check in attractive but likely buggy code to cvs. Usually you must not
include a new feature to the release branch once it is created.
However, if many developers want to include one to the release branch, then we
can discuss it in the list.
After each release, we'll merge the bug fixes to trunk. If we get used to this
release process, maybe a branch exists only for a few weeks,
and thus merging changes to trunk is not gonna be that hard.
Any comments, better idea?
Tat
------------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
