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 Tue, 15 Jan 2013 08:16:21 GMT
> 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.


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