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 (http://xml.apache.org/fop/embedding.html) 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.
Vadim
