[Flightgear-devel] RFC : FlightGear Roadmap for 2.0 and further

[Tatsuhiro N. <tat...@gm...>]

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