celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject Re: Celix release management/planning
Date Thu, 17 Jan 2013 07:59:48 GMT
On Wed, Jan 16, 2013 at 10:45 PM, Jeroen Kouwer <jeroen.kouwer@gmail.com>wrote:

> 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?

I like this idea. If we keep the date driven releases small (only bug
fixes) it should be a small effort to release a new version Celix, this
will help in keeping the work for Celix manageable. On the other hand this
also gives us the freedom to work on feature and release them when they are
ready. I do think that if we are ready to release a new Celix features wise
we should break the date release schedule and postpone a  scheduled date
release, otherwise we still have a date driven release with the version
number showing if we have introduced new features.

> [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!

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