On 25 Dec 2008, at 18:38, Tatsuhiro Nishioka wrote: > 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.
It's not quite the number system I first guessed at, and I think the odds of ever *doing* a bug-fix release are quite low, but it sounds reasonable. > 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). <snip> Overall I agree, coming from a commercial software development side, I'd prefer people to think in terms of features, and committing to delivering them for a certain release. Where a feature means the kind of thing we'd put in a 'new for this release' bullet point list. Then we can decide whether to delay a release because feature X will take an extra two weeks, or postpone feature Y from release 2.n to 2.n+1 because it would delay it too much. OGRE create a wiki page for each release - initially it's a blue-sky page, then it becomes 'live' when the release is being worked on, and finally it becomes the release notes for that release, with a list of completed features. That seems pretty logical to me. > 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 in practice, the odds of ever doing a release *branch* for a project like FG is very low. I'd rather just stabilise trunk and tag. If we ever needed to do a x.y.1 release, it's trivial to branch from the tag and fix the bug. In general, back-merging from a release branch to a trunk is a horrible, thankless task, so avoiding it seems like a win to me. James ------------------------------------------------------------------------------ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
