Reinhard Poetz wrote: > > Carsten Ziegeler wrote: > > ><snip/> > > > > > >My opinion is that we should remove deprecated classes (some > of them) > >in our 2.1.x branch *now* in order to create a smooth > transition and to > >build a better basis for the future development. > >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. > >We clearly indicate that although we have a major version > change, there > >are only minor incompatibilities that shouldn't affect users. > > > > > > Who is affected by those changes? What does an upgrade mean > for the user? > Good question, thanks Reinhard, I forgot to tell that :)
If we remove deprecated classes, users that have developed their application for Cocoon 2.0.x are affected if they are still using the deprecated classes. If your app is developed for Cocoon 2.1.x, you are not affected. An upgrade for a user means that she just has to replace the use of the deprecated class with a newer one. So it comes down to using a different interface name and a different method name in some rare cases. The two areas affected here are caching and source resolving. In both cases, using the new interfaces provides improved features but also improved performance and stability anyway. Another area are the RequestLifeCycle components. They have been introduced in Cocoon 2.0.4 (I think) and we have voted to remove them in 2.2 again. So if you are using them, you have to use one of the alternatives which is using Contextualizable to get the object model or the RequestDataStore to store infos. But I guess that not many are using these interfaces anyway. I would add of course documents on how to update for each area. Carsten
