On 8 Feb 2011, at 09:33, Dirkjan Ochtman wrote:
> Most of all, I want a better schedule/insight into the release
> process. Even when reading the dev list, it's completely unclear when
> I might expect the next release or what the blockers are. Releases
> seem to just keep slipping, or maybe releasing isn't a very big
> priority, at least that's what it looks like from the outside.
The current release cycle goes something like this:
a. Make a release
2. Add features and test them for a while
d. Schedule a new release following consensus request
It's a little more complex than that.
For step 2, we follow the roadmap that is generated in JIRA. That is, the
roadmap is constantly maintained through ticket work and ticket maintenance. A
link to this is even included prominently on the project homepage. We have
found that maintaining a HTML roadmap separately to JIRA is too much trouble.
Or, at least, we could infer that from the fact it was never updated by anyone.
The roadmap (as a JIRA view) is effectively discussed on this list, and then
codified through the tickets. I think that's Good Enough. And if it's not, then
maybe we need to be smarter about how we use JIRA.
As for step d, this tends to be a consensus based thing. Usually, one of two
things will happen. Either the time since the last release will start to grow
too large, or the amount of features added will. In both instances, discussion
usually starts to bubble up on the list, and this quickly results in a new
release being prepared. The only thing that tends to slow that process down are
release blockers. Like the last release. These tend to be heavily discussed on
the list. I also think that this is Good Enough.
[1] http://s.apache.org/couchdb-roadmap
