cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: Cocoon Gump Status
Date Fri, 21 Mar 2003 15:55:03 GMT
Santiago Gala wrote:

> Vadim Gritsenko wrote:


>> They have those classes. In the branch. Same situation as we had 
>> recently before repository split-up.
> But, If they have documented 
> ( the use of the Options 
> class, they should be aware that users are not like computers, i.e. 
> they need time to understand changes, plan for migration and migrate. 

Yes. deprecation warning should be there (like: please be warned that in 
2 years this class will be gone (see below)).

> They could keep them in HEAD, and have them in the first 1.0 release, 
> deprecated.

<sidenote>Is it good idea to start software (have first release) with 
deprecations? :)</sidenote>

> Or, alternatively, a "fop-020-compatibility.jar" could be kept in HEAD 
> with impls of those missing classes, to ease migration. This would 
> bring the extra added value of having users able to test the new stuff 
> without having to change code, while keeping them conscious that they 
> are relying on deprecated, dangerous stuff.

Nah, I don't agree with this. If I plan to maintain fop-020-branch for 
2-3 years and want to continue working on some fop-070 during this time, 
I don't want these classes be in fop-070 for two years.

2 years considered by everybody here as a long enough time to migrate to 
next version. If you haven't, may be you don't need this fop-070 at all...

OTOH, if release cycle is much shorter, then I agree with you, 
compatibility jar is a must. But only if software has been released. All 
of this is non-applicable to alpha software.


View raw message