Celix release management/planning

[Roman Shaposhnik <rv...@apache.org>]

Hi!

I was trying to figure out what is the release policy for Celix
and I couldn't find any answers. Any chance some of the
old timers can shed a bit of light on this? I'm mainly interested
in things like: whether project considers itself date driven
or feature driven, whether it tracks progress towards the
next release in a JIRA, etc.

Thanks,
Roman.

P.S. At a very superficial level I'd like to know when do you
guys think the next release of Celix should be available and
what it should accomplish.

Re: Celix release management/planning

[Alexander Broekhuis <a....@gmail.com>]

Hi all,


> I like this idea.


Me 2, This is a kinda similar to what Sascha proposed earlier in this
thread I think.


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


Agreed, making a release isn't a problem at all. For this to work we need
to write down the release procedure, but we already mentioned this during
the vote for the first release.


> On the other hand this
> also gives us the freedom to work on feature and release them when they are
> ready.


To keep things separated this work needs to be done on a branch. This means
we need to merge stuff back and forth, but I don't see that as a problem.


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

I am not sure on this one, I don't think it is a problem to introduce new
features using this method on the same schedule as small releases. I do
think however that we need to discuss the versioning a bit further.
There are two things that come to mind:
* Use semantic versioning (looking at the modularity of OSGi I personally
see this as a must)
* Have separate versions for the different parts (the framework, and the
individual bundles).

@Marcel: How do you guys do this with Ace/Felix? Especially since Apache
officially only has source releases?
A possibility I can think of is to have some sort of virtual version for
the entire source package, and have each part have its own version.

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



-- 
Met vriendelijke groet,

Alexander Broekhuis

Re: Celix release management/planning

[Pepijn Noltes <pe...@gmail.com>]

On Wed, Jan 16, 2013 at 10:45 PM, Jeroen Kouwer <je...@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!
>

Re: Celix release management/planning

[Jeroen Kouwer <je...@gmail.com>]

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!

Re: Celix release management/planning

[Alexander Broekhuis <a....@gmail.com>]

Hi all,

If the majority of the committed people think a date driven release is
needed, I am fine with it. But..

I prefer a date drive release because of two reasons:
> - community growth: I expect a better visibility of the project if it has a
> clear set of release dates and I expect that a clear set of release dates
> will lower the threshold to participate in the discussion what should be
> developed in which release. So this should help for #2.
>

I can agree with this one, although I still think making a release for the
sake of a schedule is wrong. And imho also gives a wrong sign.


> - keeping pressure on the project: Even though we only have 2 committers
> with little time, or maybe especially because, I think is paramount that we
> have a always have clear release goal and date to keep some pressure on the
> development. Date driven releases will enforce this. I know for me this
> will help in planning some spare time for Apache Celix. Also for legal
> perspective (#3) regular - maybe small - release would IMO be better, that
> way we enforce that Celix has a periodic legal check.
>

This is a personal opinion. At the moment I am not involved in any project
using Celix. So all the work I do, is done in my (limited) spare time. So I
can't and won't commit to a schedule which expects a certain feature at a
certain date.
So while I agree with a clear release goal, I can't give any guarantee
(from my point) for a release date.


> As for a release frequency I was thinking about quarterly releases. So a
> release in March, June, September and December.
>

If we go on with a schedule, I don't have any objections to these dates.


>
> That being said, I have no real problems with feature driven releases, _if_
> we ensure we always have a clear date for the next release.
>

See my remarks above, I can't and won't give any dates at this time.

All in all, we should keep in mind that there are only 2 committed people
[2]. While I really value (and cannot do without) the ideas/remarks of the
mentors, they are formally merely here to guide us through the incubator
[1] wrt the Apache Way. I can't find any docs stating that a release
schedule and/or fixed RM is needed. Looking through several projects, there
are a few wo have a schedule, but many don't. I do welcome any commitment
regarding releases/code/features, and would love to see our mentors be
involved in the development as well. This would give us more leverage
regarding a release schedule. At this moment if any one of us is
unavailable, a schedule would be useless instantly.

So to summarise, we should come up with an acceptable way of working, which
fits within the Apache Way and to which I feel comfortable. Don't get me
wrong, I wish I could invest more time in Celix, but I have to make
choices. Forcing me to do something which would contradict with these
choices would push me away from Celix. And that is something I surely don't
want!
Stating this doesn't mean I always object against a schedule, it is just
the current project size and personal situation which makes it a problem
for me.

[1]:
http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Mentor
[2]:
http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Committers

-- 
Met vriendelijke groet,

Alexander Broekhuis

Re: Celix release management/planning

[Pepijn Noltes <pe...@gmail.com>]

>
> Personally, I expect every honest release to be a combination of the:
>    #1 general feel of the developer community that this particular set
>    of source code is 'good'
>    #2 a user community vouching for the fact that by and large it
>    satisfies their use cases
>    #3 developer/PMC community vouching for the fact that to the best
>    of their knowledge the bits that comprise the release are safe to
>    use from legal standpoint
>    #4 a signal to the downstream projects that they may latch onto the
>    new set of bits and expect them to provide a stable based for them
>
>
I prefer a date drive release because of two reasons:
- community growth: I expect a better visibility of the project if it has a
clear set of release dates and I expect that a clear set of release dates
will lower the threshold to participate in the discussion what should be
developed in which release. So this should help for #2.
- keeping pressure on the project: Even though we only have 2 committers
with little time, or maybe especially because, I think is paramount that we
have a always have clear release goal and date to keep some pressure on the
development. Date driven releases will enforce this. I know for me this
will help in planning some spare time for Apache Celix. Also for legal
perspective (#3) regular - maybe small - release would IMO be better, that
way we enforce that Celix has a periodic legal check.

As for a release frequency I was thinking about quarterly releases. So a
release in March, June, September and December.

That being said, I have no real problems with feature driven releases, _if_
we ensure we always have a clear date for the next release.

Greetings,
Pepijn

Re: Celix release management/planning

[Roman Shaposhnik <rv...@apache.org>]

On Fri, Jan 11, 2013 at 11:19 AM, Marcel Offermans
<ma...@luminis.nl> wrote:
> 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.

With my mentor's hat on I'd say that 2 things are pretty important to
the project: understanding what the project plans (even if long terms)
are for the next release and being able to easily track those goals.

Personally, I expect every honest release to be a combination of the:
   #1 general feel of the developer community that this particular set
   of source code is 'good'
   #2 a user community vouching for the fact that by and large it
   satisfies their use cases
   #3 developer/PMC community vouching for the fact that to the best
   of their knowledge the bits that comprise the release are safe to
   use from legal standpoint
   #4 a signal to the downstream projects that they may latch onto the
   new set of bits and expect them to provide a stable based for them

Now, releases are NOT a given in the open source projects. In fact,
a massively successful OS project I happen to be a part of (FFmpeg)
used to make a point out of NOT having formal releases. The rationale
there was that even thought we all were extremely comfortable at
claiming #1/#3 pretty much for any arbitrary point of our trunk
(we practiced a 'golden trunk' development model) we had no resources
nor interest when it came to investing in #2 and #4.

That flexibility, of course, was a direct consequence of not being part of
any umbrella OS initiative. If you're just on GH or SF -- you can have any
governance model.

I think it would be fair to say that being an ASF project comes with an
assumption that you will find time and resources to invest into all 4
of the above things. To some extent it is a bit of a forcing function
(especially #3) and it needs to be budgeted in when a project decides
to go with ASF.

Hence, as a mentor, I'd expect Celix to figure out when it is time for
it to have such a next milestone. It doesn't have to be full of exciting
new features, it just has to provide some level of incremental
progress and also deliver on #1-#4.

Let me know if you guys need any help with driving the release. Also,
I think at some point I might inquire about somebody potentially
volunteering as an RM.

Thanks,
Roman.

Re: Celix release management/planning

[Marcel Offermans <ma...@luminis.nl>]

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....@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!
>> 
> 
> 
> 

Re: Celix release management/planning

[Sascha Zelzer <s....@dkfz-heidelberg.de>]

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

Re: Celix release management/planning

[Alexander Broekhuis <a....@gmail.com>]

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

Re: Celix release management/planning

[Pepijn Noltes <pe...@gmail.com>]

Hi Roman,

On Tue, Jan 8, 2013 at 1:48 AM, Roman Shaposhnik <rv...@apache.org> wrote:

> Hi!
>
> I was trying to figure out what is the release policy for Celix
> and I couldn't find any answers. Any chance some of the
> old timers can shed a bit of light on this? I'm mainly interested
> in things like: whether project considers itself date driven
> or feature driven, whether it tracks progress towards the
> next release in a JIRA, etc.
>

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.



>
> Thanks,
> Roman.
>
> P.S. At a very superficial level I'd like to know when do you
> guys think the next release of Celix should be available and
> what it should accomplish.
>

There has been a discussion on what should be in the next release [1], but
we have not yet discussed a date.


[1] http://markmail.org/message/5zhfugurztlaha6d

Greetings,
Pepijn