celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: Celix release management/planning
Date Fri, 11 Jan 2013 19:19:47 GMT
I agree with Roman that it's good to have some kind of plan or roadmap, feature or date driven.
Personally, I would like to see regular releases, even if they contain only minor updates.
If big feature implementations would block releases, we could consider developing them on
feature branches.

Greetings, Marcel

On Jan 10, 2013, at 14:32 PM, Sascha Zelzer <s.zelzer@dkfz-heidelberg.de> wrote:

> Hi,
> 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".
> Best,
> Sascha
>> 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