cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Releasing 2.2
Date Mon, 23 May 2005 09:02:33 GMT
Carsten Ziegeler wrote:

>Ralph Goers wrote:
>  
>
>>I doubt many will switch until 2.2 is stable - i.e we've had a few 
>>releases of it.  I would recommend that we continue doing maintenance on 
>>2.1 until at least a stable 2.2.0 is released and possibly a release or 
>>two later.  That doesn't mean that new features need to be backported to 
>>2.1 though.
>>    
>>
>Exactly. It took a long time until the majority updated from 2.0 to 2.1;
>and still there are many installations out there using 2.0.x. So we have
>to maintain 2.1.x for a long time.
>But as soon as 2.2 is final we don't have to sync the branches anymore,
>just for bugfixes.
>  
>
I think you are mixing cause and effect: 2.1 and now 2.2 become unstable 
because we *let* them become unstable. We removed them from extensive 
user testing and feedback by marking them usstable. And user testing and 
feedback is the only thing that creates *real* stability. As developer 
your testing is always limited to your own prejudices about what the 
feature should be used for.

By marking the 2.1 and 2.2 unstable we also created the impression that 
it is ok to add new features without discussions and tests and that 
someone else will take care of the problems later. Also it creates 
discontinuity, people avoid going 2.0->2.1 and 2.1->2.2 because so many 
changes has been allowed to add up during the years between the minor 
releases, so that it will require a lot of work to port.

As we have let this happen for 2.2 we must of course maintain 2.1 for a 
while and go through an alpha->beta->stable cycle for 2.2. But I really 
think we should avoid this mess in the future.

                                                   --- o0o ---

So lets evaluate what we have gained by spliting in a 2.1 and 2.2 
branch. It was supposed to be necessary for developing "real blocks", I 
don't see that it has helped us and I fail to see why it should be 
necessary. And as being active in this area I should know at least 
somthing about it.

If we take a look on what is new in 2.2, we copied the ECM to the Cocoon 
repository and changed the package names. I don't think that introcuced 
any instabillity. After that there have been various refactorings of 
ECM. If these have introduced back incompabilities, there should have 
been votes about it, if there hasn't been votes it rather shows that it 
is dangerous to have a "playground" branch.

I don't think that the introduction of includes in cocoon.xconf, lazy 
loading of components, local classpath for sitemaps, or hosting of other 
IoC containers (see 
http://www.anyware-tech.com/blogs/sylvain/archives/000171.html) should 
have caused any incompability or instability for those not using it.

For those things I have been involved in: JXTG refactoring was done 
without disturbing uses of the original one until the community felt 
confident with switching. The same process could have been followed in a 
stable branch. And we probably would have got more testing as the ablity 
to use it without flow is a feature that several users have asked for.

VPCs have not affected existing functionality, they could actually even 
have been developed in an own block.

My work on "Sitemap blocks" haven't affected any existing functionality 
either and can be moved to a block if we want.

                                                   --- o0o ---

Probably I'm missing important aspects, but I fail to see what the split 
into trunk and stable have bought us, except for less testing, 
disruption and possibly sloopier coding as the branch is supposed to be 
unstable anyway.

/Daniel


Mime
View raw message