cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [RT] Versions
Date Tue, 20 Apr 2004 10:28:48 GMT
Joerg Heinicke wrote:
> 
> 
> > only
> > if we remove deprecated code, the environment handling can be 
> > improved. Or in other words: backporting to 2.1.x would require to 
> > remove deprecated classes which could really affect users.
> 
> What does "remove deprecated classes" mean? I guess only the 
> usage of them or not? The classes itself can stay where they 
> are (or moved to src/deprecated or whatever).
> 
See my answer to Reinhard's question for more info. In addition:
no, it's not possible to just remove the usage in all cases as
for example for the source resolving we changed the interface
and removed deprecated methods.

> 
> > Following this logic, it would mean that if we would rename the 
> > current 2.1.x version that we have in the CVS to 2.2, users 
> would not 
> > update just because of the version name and not the content!
> 
> IMO we should just make clear that the 2.1 => 2.2 upgrade is 
> not that major than 2.0 => 2.1. But that's only true if we 
> release the first version of 2.2 short after the fork from 2.1.
> 
Yes.

> On the other hand I didn't get the feeling that there were 
> many problems when upgrading from 2.0 to 2.1. This might be 
> due to not upgrading at all of course.
> Probably users start a project with a specific Cocoon 
> version/the latest release at this time. During the project 
> they do only the minor upgrades. When starting the next 
> project they use the latest available version at that time 
> again. So upgrade problems might be only rarely reported.
There were many complains from users that upgrading from 2.0.x
to 2.1 wasn't that easy.

> 
> > To indicate this, we should update the version number to 
> 2.2 *now* in 
> > the cocoon-2.1 repository. This would mean that the next Cocoon 
> > version would be 2.2. If the need for a 2.1.5 arises we could still 
> > make a branch.
> 
> Now the confusion starts. IMO we should have clear 
> version/repository matchings. 
> 
Yes, a clear matching is required. We would have the clear matching
of "Any cocoon version >= 2.1 is in the cocoon-2.1 repository" :)

> > Of course, if we follow this road, our repositories would 
> have wrong 
> > names, but this imho doesn't really matter and we could rename the
> > cocoon-2.2 repository without any problems.
> 
> I don't agree. This naming issue really matters. It's IMO 
> much more important than non-upgrades during project's 
> lifetime. If we follow the proposal the above cries for a 
> cocoon-2 repository (the current 2.1) to make this at least clear.
> And each branch is moved into a new repository. 
Now, actually, I didn't want to get into the "repository vs. branches
and naming" discussions :) Ok, but we don't need to make a repository
just because we change the version number. It only makes sense
if we continue the development. We end up in to many repositories
that are actually unused.
I don't see any problem with branching a previous version if
the need arises.

> But not not 
> the stuff is branched out, but only the old one. This would 
> make it consistent with the current cocoon-2.0 and make an 
> upgrade easier for people living from CVS. This also means a 
> 2.2 release would result in a cocoon-2.1 repository as 
> quasi-branch point.
Checking out a branch or a tagged version from CVS is as easy as
checking out the head.

Carsten


Mime
View raw message