Tatsuhiro Nishioka wrote: > 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 > This is a good idea, regardless of the specific milestones that make it into a release. It seems to me that just the data tree sees enough new development that quarterly releases would have interesting new content. > > 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...) This sounds nice, but we, or at least I, can't commit to specific features or development on a fixed timescale.
> > > 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 this is a very good idea, and the work like shadows could start going into a "bleeding edge" branch soon. I think we need a "stable" branch, even with quarterly releases; new code and fixes are checked in all the time that our power users want, even if they aren't willing to break their world with experimental stuff. That said, I cannot bear the thought of setting up this parallel branch structure (to say nothing of the plib branch, that sees some fixes from time to time) in CVS. I know it's possible in CVS, I've worked on many hobby and professional projects that use CVS branching, and there is always some fiasco that happens in the course of making or merging branches. I don't have the bandwidth to deal with those headaches on a hobby project. Thus, I won't support a bleeding-edge branch until we move to a revision control system that properly supports branching. We can debate this 'til the cows come home, but Git is the only rational choice for a replacement VCS. It has the features, the community, and today has the user friendliness and Windows support to be used by everyone who wants to compile current FG development sources. It is already being used by a critical mass of FG developers. Tim ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
