cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reinhard Poetz" <>
Subject RE: on better release and version management
Date Thu, 11 Sep 2003 12:19:00 GMT
Hi Steven,

Thank you very much for your answer. It opened my eyes in some respect
(especially the point with positive FUD). I thought again about our goal
and I found two of them:

 - make it possible to continue with 2.1.x releases
 - start ASAP with 2.2 without influencing 2.2

And the simplest solution (and probably the only that will work) is

Find more comments in the answer to Bruno's posting.

Best regards,

> -----Original Message-----
> From: Steven Noels [] 
> Sent: Thursday, September 11, 2003 1:39 PM
> To:
> Subject: Re: on better release and version management
> Reinhard Poetz wrote:
> > I expect this and that's the reason why I think that a stable 2.2 
> > release will take some time (I think that's not a matter of a few 
> > months but much more) and why I like Carsten's proposal.
> Grmbl. Bruno and I were just trying to argumentize against each other 
> about both scenarios, and I'm stuck with a few issues that I 
> would like 
> the repository reshuffling see resolve.
> Here's some feelings (not facts) I want to share with this discussion:
> 1) There's a decent amount of (positive!) FUD about the new 
> blocks. All 
> in all, I don't think that the actual coding of the new 
> classloading and 
> block deployment architecture code is much more cumbersome that what 
> Sylvain once did with the TreeProcessor, and Stefano did with 
> the build 
> system. Yes, it will take time, but it's just a matter of 
> finding time, 
> motivation and energy to do the job. We tend to discuss for a 
> long time 
> about such issues, possibly longer than the actual coding actually 
> requires. In the end, it's about getting on with it, and 
> someone (which 
> we will be very grateful for) diving deep into it and 
> resurfacing when 
> it's done. Ditto with Fortress. I'm naively hoping that some F2F time 
> during the GT will help in finding that energy, and getting some 
> commitment from people who need to shift between for-pay and for-free 
> work on a daily basis.
> 2) My main concern with all this restructuring is however release 
> management, and the user-facing perspective of our community work. We 
> need to arrive to a situation where blocks can be 
> independently released 
> from Cocoon core releases, so that people who feel a faster drive to 
> work on specific features can get on with the job, without being 
> demotivated by long periods of no releases due to one zillion 
> dependencies. So maybe we should move all blocks code into a separate 
> module, and establish an independent release schedule (at the whim of 
> the actual block release manager) for them.
> 3) This brings us to the eternal discussion about the 
> definition of core 
> and non-core. Maybe, be splitting out block code from the 
> main module, 
> and actively trying to slim down the main one even more, we 
> will end up 
> with a better community sense of what can be considered 
> 'core', and what 
> should be consired a block. We could even consider the 
> TraxTransformer a 
> block on its own, if we restrict the core to the pipeline, caching, 
> sitemap and flow machinery. We could envision a packaged 
> stable build of 
> Cocoon which includes the core and then some core blocks. The rest is 
> developed and released on its own schedule, and can, given the 
> dependency checking in the new blocks paradigm shift (yes, it's more 
> about a shift of perception than actual rearchitecturing) be safely 
> released outside the main release schedule.
> This is just a quick braindump of my current feelings about all this. 
> Hopefully it can contribute positively to this recurring discussion. 
> Ending on a filosophical note: in the end, we should be 
> driven by hope, 
> not by fear. If we manage to come up with a stable 2.1.2 
> release within 
> some weeks, I'm pretty sure our users have plenty of new, stable 
> releases to play with while we get our act together.
> </Steven>
> -- 
> Steven Noels                  
> Outerthought - Open Source Java & XML            An Orixo Member
> Read my weblog at  
> stevenn at                stevenn at

View raw message