cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: [RT] Releases
Date Sun, 22 May 2005 12:58:29 GMT
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
--------------------------------------------------------------------


Mime
View raw message