celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
Subject Re: Celix release management/planning
Date Thu, 10 Jan 2013 12:29:15 GMT
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.

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!

-- 
Met vriendelijke groet,

Alexander Broekhuis

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