View Single Post
  #9   (View Single Post)  
Old 8th June 2008
phoenix's Avatar
phoenix phoenix is offline
Risen from the ashes
 
Join Date: May 2008
Posts: 696
Default

Both systems (feature-based "ship when it's ready and not before" and time-based "ship whatever is working on this date") have their pros and their cons.

The biggest con for a feature-based release schedules is who gets to decide which features are the must-haves, and how long are people willing to wait to get them in shippable shape?

The biggest con with time-based release shedules is the lenght of time you select (6 months, 9 months, 12 months?), how much effective work can be done in that time (ie how much is devoted to testing, QA, and RE), and what to do when features aren't complete at the cut-off (how many times can one feature be bumped before people get mad?).

For major, revolutionary changes, feature-based schedules work better. For minor, incremental changes, time-based schedules work better. Merging the two methods (which is what I believe they are aiming for) is a good mix: a major new release every 18-ish month, a minor release every 6 months.

That way, development happens in -CURRENT, with -STABLE branches made every 18-ish months, with all the big, major changes happening there. When the new features are ready for release, they are included into the next major release (or MFC'd to previous releases if possible). And new releases are made from -STABLE (X.1, X.2, X.3) every 6-ish months with whatever new developments have occurred since the last minor release.
__________________
Freddie

Help for FreeBSD: Handbook, FAQ, man pages, mailing lists.
Reply With Quote