cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Releasing 2.2
Date Mon, 23 May 2005 11:51:31 GMT
Carsten Ziegeler wrote:

>Daniel Fagerstrom wrote:
>>That is a reason for increasing minor version, but not for maintaining 
>>parallell branches for years.
>If we don't maintain the "old" 2.1.x branch, what about all its users?
>Do you want to force them to migrate to 2.2? That's simply not
>realistic. We should be able to provide bug fixes for all those out
>there using our project.
Have never disputed that we have to maintain 2.1 for some while and that 
we must go the alpha->beta->stable cycle for 2.2.

My message is that I fail to see that we gained anything from creating 
an unstable development branch and that we should avoid doing that 
mistake in the future.

If we want to remove deprecated code, we have a routine for that: wait 
long enough time, so that everyone have had the chance to do anything, 
vote about it, remove the code and step up the minor number. If we at 
that point feel that we still need to maintain the previous version, it 
means that we removed the deprecated code to early and the we probably 
should readd it and schedule the removal to the next minor release. 
Mainteining two versions because of to early removal of deprecated code 
seem like a bad idea.

For API changes the situation is obviously more complicated, so we must 
really know what we are doing and if possible make it possible to use 
the new and the old in parallell for some while.

If this can't be done, we need to maintain an old branch for a period. 
But in this case we should try to decide for how long time we maintain 
it and remove it afterwards. And it should IMO be marked as a 
compability branch rather than the stable one.

IMO we should really try to let trunk contain the stable branch in the 
future. The idea of an unstable development doesn't seem to fit well 
with our *actual* community dynamics. And it doesn't fit well with agile 
development methods either. And it is IMO highly questionable if it has 
done anything good for us since 1.0->2.0. To me it rather seem to hurt us.


View raw message