Hello, Why not have a combination of both a date and a feature driven release planning?
Personally, when I look at whether a project is still alive, one of the first things I check is the date of the latest release. To me this is a very strong indication of whether the project is still alive (and hence worth spending my time on) or not. For this reason I would like to see a date driven release for celix, provided there are real changes in the release. On the other hand I can appreciate Alexander's concerns regarding releasing just for the sake of having a release and the pressure a date driven release puts on the developers of celix [1], which would vote for having a feature driven release. But I think it is possible to have the best of both worlds by combining both approaches. Have a date driven release planning that is geared towards maintenance (containing mainly bug fixes), indicated by increasing the third number of the celix version (provided celix adheres to the major.minor[.maintenance] scheme [2]). Such a release should only be done when there has been some change on the trunk. When there has been really no change on the trunk the date driven maintenance release should be cancelled. This way the frequency of the maintenance releases reflect how alive the project is. And keep in mind that one change on the trunk is enough justification for a maintenance release. Currenctly potential users of celix are referred to the trunk in order to not miss out on maintenance [3]. In order to let the user base grow I think it is much better that users can be referred to the next maintenance release (due on <fill in date of next date driven maintenance release>). Besides these date driven maintenance releases a feature driven release plan can be made, which would be reflected in changing the major or the minor number of the celix version. Exactly what features would go in the minor increments and the major increments should be recorded in a release plans and roadmaps. For these releases can be clearly stated that they are not, repeat not, date driven, but will be released when the features are ready for release. When such a release is ready it can be introduced on the celix web site and scheduled on the date of one of the next maintenance releases (as not to break the release frequency). With this release management/planning celix could build up a user base by drawing attention to itself by having regular releases. The actual maintenance releases would be an honoust indication of the activity on the project and there would be no pressure to deliver new features on a certain date. How does this sound to the comitting members of the celix community? [1]: http://markmail.org/message/fc57catu7yfnzzho [2]: http://en.wikipedia.org/wiki/Software_versioning [3]: http://markmail.org/message/owr2dz27bhfafm6d Kind regards, Jeroen Kouwer -- :wq!
