Sam, Sam Ruby wrote: > > ... > > Just to clarify - FOP may or not be building off of the xml-batik CVS > repository, but I do. The reason why I do is exactly to provide early > warning of such impending changes in order to promote discussion.
Understood, and thanks for doing what you do: it is helping us right now! > > > What is happening is that we are fixing what we think was a design > > error and we are removing a parameter from a large number of methods > > in GVT, one of the core Batik modules. You are right, we are not > > deprecating the old signature, even though I agree deprecation is > > good practice. > > You are also adding a parameter to a fair number of methods. Note that in > this case, we are discussing an interface, so it is not clear that > deprecation of methods is an effective means of providing backwards > compatibility. Any additions or changes will require source code changes > to implementors of this interface. Yes, you are right. So I think we agree deprecation is not a good solution in our case. > > ..... > > One thing that works in some occasions is to rename the interface, and for > a period of time support both the old and new interface. > This would be very difficult here. There is not only one interface or class which changed but a fairly large number. Therefore, the dual support (old/new) did not seem like a viable option to us and especially to Thierry who made this difficult, widespread change. > > Here is what I suggest: > > > > a. Short term, build using the batik 1.1rc2 release. > > b. Wait until Thomas completes the wide-spread changes Thierry has > > started (this will further impact the TextPainter interface). > > c. Once the API is stable again, update your TextPainter implementation > > so that it no longer uses GraphicsNodeRenderContext. > > d. Then, you can either use the Batik CVS again or use our next > > developer release. > > The thing to consider here is that often batik and fop are often used in > combinations with other components. An example I mentioned in my previous > e-mail was cocoon. Even after the next release of batik, cocoon may need > to hold back support for this new release lest it steps up to a release > that fop does not support. And even cocoon is a component that others may > choose to build upon. > > In general, it is not possible to coordinate the upgrade of every user of > an open source project. > > The overall strategy which I recommend is that every time a breaking change > is required, try to have at least one public release in which both the old > and new interfaces are supported, with the old interfaces deprecated. I understand your arguments and I agree with them, but I would also point out that implementing both the old and new interface can be a costly proposal in terms of development effort. So, I think that we should consider implementing the old/new interfaces in regards to the cost/benefit ratio. For example, depending on how public is the API change, we may decide to have the intermediate step or not. What I mean by 'how public' here is that a change to the internal interfaces/classes of a module (like in our case) is a lot less likely to cause problems than a change to the very top level APIs (SVGGraphics2D would be a good example in Batik). Therefore, the amount of efforts required may or may not be justified. Of course, the FOP extension of TextPainter shows that we have a user where we thought we had none, but the cost of implementing both the old and new interfaces would have been pretty high... In summary, I think we are in an unfortunate case that, thanks to your efforts, was spotted early. Your point about having an intermediate step with old/new interfaces is well taken, even though I think it does not apply to the specific situation we are discussing (given the cheer volume of changes in our GVT module). It will, however, apply to many changes we will face in the future. Thanks, Vincent Hardy. > > - Sam Ruby > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
