Time- vs. feature-oriented releases
When you plan the next release of your application you have to answer one important question: when will I release? You can answer this question in two ways: you simply define a release date (i.e. it is a time-oriented release), or you define a set of features the new release will contain (i.e. it is feature-oriented). That means in the first case the time is fix, but the features are variable, whereas in the second case the time is variable and the features are fix. Quite common is also the situation that both, time and features, are fix.
Let’s have a closer look at those options we have at our disposal when planning a release.
Time-oriented releases
Time-oriented releases have a fix release date. If we see we cannot make it, then we either have to delay features to the next release, or we have to switch features, i.e. an “easier” feature gets implemented instead of a planned feature. On the other hand, if there is some time left until the release date you can implement additional features.
The challenge with time-oriented releases is to find the right time frame. Is it too short, it is difficult to implement something of value. Is the release date too far away, then there is no release “pressure” and people slow down.
An example for time-oriented releases is the Scrum process, there you have at the end of each iteration a release (i.e. every two to four weeks there is a new release).
Feature-oriented releases
With feature-oriented releases you define a set of features you want to have implemented before you release. There is often no release date announced, or it is rather vague like “we plan a release for spring 2008″.
The challenge here is to find the right set of features. If you select too many features, then the implementation takes “forever”. In the other case you may have too many releases with not much value.
As an example for feature-oriented releases we probably can take CakePHP, as its releases follow the motto “it is done when it is done”.
Time-and-feature-oriented releases
A combination of the two aforementioned approaches are time-and-feature-oriented releases, where you have a fix release date plus a set of features the release must contain.
The challenge here is that you often need a variable element you can adjust to deliver the release at the planned date with the planned features. You can add more people to the project, work longer, and/or decrease the quality.
Examples for such time-and-feature-oriented releases are projects which have to be live at a certain date, e.g. an advent calendar application has to be ready at the first of December.
As you see, each approach comes with its own challenges. There is no best approach. It depends on your specific situation/project.
[...] Source : Time- vs. feature-oriented releases [...]
There is a fourth alternative which is a modern rendition of the ‘Feature-oriented’ - the ‘Evolutionary Release’. Primarily for hosted or web services, this adds individual features (or enhancements to existing features) without any visible upgrade path. They’re generally of the “done-when-they’re done” type, but do not require any action on the part of the consumer of the service - the ‘upgrade’ simply appears the next time the service or API is used.
As a developer, the evolutionary approach can present a challenging when trying to maintain consistent APIs and interfaces, but it can also relieve your customers’ fear of the ‘rip and replace’ mentality of traditional mega-feature upgrades.
@GreyCells: Thanks for mentioning this fourth alternative I forgot!
Different approaches are also depending on the users of software products. If the users are website visitors who don’t really care about the revision of the web application, any ‘release’ approach can be applied. Contrarily, users of CakePhp are developers who care about the revision and stability. The question when 1.2 becomes stable is one of Frequently Asked Questions. Some smart people even ‘invented’ mechanisms to deal with the cakePHP’s constant change (http://www.ad7six.com/MiBlog/DRYSetup ,I like this article, btw)
I decided to use one of the ‘stable’ alpha revisions for production. I know there are a lot of enhancement tickets that need to be closed or implemented. But my hope is the core developers could re-evaluate stabilizing vs. adding new features/enhancements. Xmas is coming and a time-oriented release for this Xmas is expected :), at least by me. Remember the gift last year?
@Zonium: Thanks for your comment!
What I described was more from the perspective of the developer/project manager. But you are right, the users of the product are also a factor you may have to consider when deciding which release approach to use.
And regarding cake release, I hope there will be a new release around Xmas, but I am not sure there will be one…
I think, that is very important the user testing and that in degree in that more users uses the cakephp 1.2 would let to improve the cakephp framework in a way more fast and collaborative.
The decisition of to have in a beta state the cakephp framework 1.2 get to more users to think in to change to a framework more formal (with support enterprise, for eg. Zend Framework).
Actually I’m working with cakephp 1.1.x and I know that that’s framawork have bugs, some knowed and others in the shadows.
Well, in resume I think that is very important to have a release in Stable state of cakephp 1.2.
Best Regards
Edwin Sandoval
Web Developer of Syscom - Mexico
@Edwin: Thanks for your comment!
I agree with you that it is good that many users use cakephp 1.2 and test it. And yes, it is important to have a stable release soon, as cake 1.2 is already too long in the alpha state.