cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject [RT] Releases
Date Sun, 22 May 2005 10:46:08 GMT
(was: [RT] Micro kernel based Cocoon)
Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
>> We should move 2.2 out the
>> door as soon as possible and target "real blocks" for a later release.
>> So, try out OSGi if you want, but please not in the trunk.
> And AFAIU it's out of discussion that the OSGi layer will be part of 
> Cocoon 2.2 - although it would be helpful to define what Cocoon 2.2 will 
> be in order to get it out - in the past all my efforts to reach a common 
> understanding were not very successful :-(

AFAIU our current release and "project management policy" is based on:

* Reaching a common understanding on what should pe part of a specific 
* Document this in the Wiki or even better in Bugzilla.
* Finish all the tasks.
* Have a period of testing.
* Release it.

This all looks like a traditional and responsible way of doing things. 
But except for some short bursts of activity when one or a few people 
have felt strong enough itch to lead such a process, it is rather far 
away from our everyday business.

The work that actually gets done is based on that someone have a strong 
enough itch, and rather seldom on some central planning.

To illustrate that our current understanding of releases doesn't fit the 
community dynamics we actually have, you can take a look at and and 
ask yourself which points you actually are going to contribute coding in 
the next few months.

Since 2000 we have managed to ship a handfull of 2.0 and a handfull of 
2.1 releases. Considering the amount of activity and the volume and 
quality of what have done during that period it must be a hard to beat 
record in conservative version numbering ;)

                   --- o0o ---

IMO we should find a less demanding and more realistic attitude for 
Cocoon releases, so that we can go towards "release early, release often".

Planning what should be part of the next major release seem harmfull, as 
the relase can stall forever if there is a difference between what we 
would like to have in the release and what we actually are implementing.

                   --- o0o ---

IMO we should *only* work at trunk. No "stable" branches, we should 
instead making sure that core functionality always is stable, and find 
incremental ways for changing core functionality.

If we, after having voted about it, introduce back incompability, it 
means that the next release should go from 2.1.x to 2.2.0 e.g. It 
shouldn't be a greater deal than so. We can also step up the version 
because we feel that we want to marketing some important addition.

We should base our releases on what we actually have done rather on what 
we wish that someone else should develop.

                   --- o0o ---

For our current situation I think we could release a 2.2.0 right away. 
It doesn't contain what we planned for but OTH it contains a lot of 
goodies that we didin't plan for and that should be usefull for a larger 

When/if we finish the blocksl, or some other important stuff we can 
release 2.3 or even 3.0 if we feel like it.

                   --- o0o ---

I haven't made much release related work in the past and its far from my 
number one itch right now, so this take this semi rant for what it is.

But IMO we should stop this wishfull thinking based "major next version" 
  nonsense, sooner rahter than later. And also stop difussing our energy 
in pointless branching.

We should be proud of what we *actually* achieve, and step up the first 
decimal as soon as we have added some important feature.


View raw message