Daniel Fagerstrom wrote:
(was: [RT] Micro kernel based Cocoon)
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
<snip/>
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.
<snip/>
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
release.
* 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
http://wiki.apache.org/cocoon/22Planning and
http://issues.apache.org/bugzilla/showdependencytree.cgi?id=25322 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 ;)
yes, this also gives people that don't follow the mailing list the impression,
that Cocoon isn't an agile project.
--- 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.
yes, that's my conclusion too. (For now I will stop to write any plans or enter
bugzilla entries.)
--- 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.
I agree
--- 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
audience.
yes
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.
--
Reinhard P�tz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
