Tat wrote: > I'm very happy that we finally released 1.9.0.
Thanks for your hard work in making it happen! > 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. A roadmap would be a great idea. However, I'm not sure a quarterly release cycle is realistic. Allowing for a 2 week RC test, you're talking about less than 3 months of actual development between releases. That's not much time. For example, I think we've had 3D clouds in CVS for 3 months at least, and we certainly haven't ironed out all the bugs yet. > 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'd prefer to name something 2.0 or 3.0 when we think we are producing a major release, with significant new features. Producing 3.0 simply because the last release was 2.9 will set false expectations for users - they will be expecting significant feature improvements. Much better would be 2.01, 2.02 ... that gives us much more leeway before the next major release. > 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. That's certainly sensible. > 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...) These seem like sensible goals for a 2.0 release. However, they appear to be very dependant on Tim and myself. Regarding 3D clouds: - There are significant ordering issues, quite apart from the challenge posed by creating stratus layers. Frankly, unless someone else is intending to spend significant time writing 3D clouds _code_, I don't think 3 months is going to be enough time for me to fix all the issues. I made myself enough of a hostage to fortune last time by saying I'd have them ready by Christmas - I'm not making that mistake again ;) I believe Tim has spent some time working on Shadows (don't know about landing lights). He's much more sensible than me and hasn't said when he'll have any code ready ;) Pushing for a release in 3 months without any commitment from the developers involved in the main feature improvements is pretty high risk. [We'll gloss over the fact I'd be a bit disgruntled being told when to have something ready. That's far to close to work, and FG dev is pretty close already ;) ] > Reliability: > - NaN things must be eliminated I completely agree on this one. > 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 As far as I am aware, none of those documents is up to date, or reflects current development. I think a roadmap checked into CVS would be more sensible. We have a docs repository for exactly this sort of thing. At the very least it would mean that some random user can't just add features to the roadmap. <snip> > 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. I think cutting a release branch just prior to the release makes sense, but having long-term release branches and only merging from trunk when you're confident a feature is finished and bug-free is going to be a piece of bureaucracy that will turn developers away. I suspect we'd end up in much the same place we were in prior to the 1.9 release, where a large segment of the user population was using CVS snapshots because that is where all the cool features are. Bear in mind that we're still on CVS, so merging isn't as easy as with SVN. Particularly if the release branch differs significantly from trunk CVS. > Any comments, better idea? I'd suggest a release every 6 months, with a feature freeze one month beforehand. The release branch is cut at feature freeze. That gives a decent period for development and bug fixing. I don't think 1.9 was as bug free as previous releases, so we really need more time to find and fix bugs. Given the challenges we've had simply trying to release annually, jumping to quarterly release is unrealistic. Let's try to walk before we run. -Stuart ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
