celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeroen Kouwer <jeroen.kou...@gmail.com>
Subject Re: Celix release management/planning
Date Wed, 16 Jan 2013 21:45:46 GMT
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!

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message