celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sascha Zelzer <s.zel...@dkfz-heidelberg.de>
Subject Re: Celix release management/planning
Date Thu, 10 Jan 2013 13:32:56 GMT

First, congrats to the release!

Regarding the release policy, I made a few comments below.

(just my two cents)

On 01/10/2013 01:29 PM, Alexander Broekhuis wrote:
> Hi all,
>> As far as I know we don't have a release policy yet, although I think this
>> will be beneficial for Apache Celix.
>> My personal preference would be date driven releases, but I am curious what
>> the rest thinks.
> In the thread mentioned by Pepijn I already state that I do prefer to use
> Jira for issues.
> Regarding a release cycle, I actually don't prefer a date driven cycle.
> Why not?
> * We currently don't have many users/committers relying on releases
> * The committers have little time, so keeping a planning will be really
> difficult
> * Making a release to satisfy the schedule feels wrong to me, we either end
> up having releases with half-done/half-broken features. Or we end up with
> quick/dirty solutions for features.
 From my experience with working in a larger open-source project, I tend 
to prefer date-driven releases, *if* the daily development is not done 
on the main code line but in feature branches. Our recent switch from a 
feature-based release cycle to a date-driven process was highly 
beneficial in terms of visibility, community growth, and confidence in 
the project.

Previously, releases did happen very rarely since there was always 
someone who wanted to put yet another feature into the next release, 
leading to more bug-fixing and testing. For a smaller development, this 
might not be a problem.

What's more is that the date-driven process based on our master branch 
took away the "excitement" of "releasing something" which turns out to 
be a good thing. Making a release just means taking a snapshot of the 
master, fixing critical bugs for a fixed time-period and then the code 
is just released after all tests run successfully, documenting the 
remaining bugs as "known issues".



> I prefer a feature driver plan, and the outline in [1] was a first attempt
> of me to get a feature list.
> What I do like is to have a release more often. So while the list has
> several items, I don't object releasing if one or two items are done. But
> we should keep in mind that making and voting for a release also takes
> quite some time. There are some incubator project trying to release 2
> weekly, imho this just isn't viable. A new release is already due while the
> previous one is not yet available.
>> There has been a discussion on what should be in the next release [1], but
>> we have not yet discussed a date.
> At this moment I don't think it is possible at all to discuss a date, at
> least, not for me. All my Celix work is done in spare hours etc. So I can't
> commit to that much at this moment. A feature driven release is no problem
> for (as stated above).
>> [1] http://markmail.org/message/5zhfugurztlaha6d
> Any other ideas are welcome of course!

View raw message