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
