cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: on better release and version management
Date Wed, 10 Sep 2003 15:40:16 GMT
Steven Noels wrote:
> Hi folks,
> forgive me for putting on my BOFH hat, while making the following 
> observations...
> 1) We suck at freezing and stabilizing the codebase prior to releases.
> I would suggest that, from now on, the Release Manager puts forward a 
> release date after discussion on the dev list, and that there's a 
> two-day (!) freeze period where only glaring bugs can be fixed after a 
> vote (!) on the list.
> The Release Manager him/herself is also only allowed to commit obvious 
> version number changes and all that during this two-day "Sperr-zone".
> During the past few releases, there was a flurry of quick fixes and 
> commits happening just hours before Carsten made the tarball, and while 
> I'm not immediately aware of any nasty side-effects caused by this, it 
> sure doesn't look like there was time for any peer review on these late 
> commits, neither did it look organized at all.

+1 Yes, we should handle the release process more restrictive.

> 2) We need to break from the impasse of 2.1.1 vs 2.2
> I suggested yesterday night that the reshuffling of docs that Carsten 
> started really seems more apt for a 2.2 release. Also, the switch to 
> Fortress and Real Blocks are destined towards that 2.2 release. I 
> understand some Avalon peeps are glad to dive in and help us with that, 
> which is great, but we should facilitate them.
> Some people want to start with a 2.2 CVS module right away, others seem 
> more relunctant and want the HEAD of 2.1 to evolve into 2.2. We need to 
> decide on this, since it's blocking progress.
> My personal opinion is that 2.2 might warrant its own module, but we 
> need to discuss its structure and coexistence with old-style blocks code 
> in more depth before we ask for its creation to the infrastructure peeps.

But we should priorize all maintenance tasks first. For example the patches 
in Bugzilla: it will be more and more effort to patch Cocoon's code. What 
happens? The older Cocooon versions are as nearly as dead. See 2.0 - who 
cares about it? The same will happen with 2.1 if we open a 2.2 CVS module. 
c'est la vie? Evolution?

> 3) Given the breakage in the Rhino stuff, and the lack of serious 
> testing on the 2.1.1 release, I would refrain from announcing 2.1.1 (not 
> retracting it, though) and go for a new target release date for 2.1.2 on 
> September 24th. That way, we can discuss at leisure what we are going to 
> do with the docs-reshuffling, and people can spend more time on testing 
> new stuff.

I guess the 2.1 had more and harder errors (e.g. the impossible undeployment 
in Tomcat), so I think it's no problem to announce this as improvement 
including the notice, that there is now another problem. It's ok IMO, if the 
2.1.2 follows in a little while.


System Development
Fon  +49(0)341-979-7419
Fax  +49(0)341-979-7409

View raw message