On 02.06.2003 14:12:43 Thomas E Deweese wrote: > >>>>> "JM" == Jeremias Maerki <[EMAIL PROTECTED]> writes: > > JM> However, I'm worrying about binary compatibility. At the moment we > JM> have to tell our users that they have to use the Batik-version > JM> delivered with FOP. I'd like to see Batik's API stabilize some > JM> more so people can just download the latest version of Batik and > JM> replace it in their installation. I realize that FOP is a somehat > JM> special Batik customer from an API-POV. But let's take Cocoon: It > JM> contains blocks for Batik and FOP (where FOP uses Batik for SVG > JM> support). If a Cocoon user needs to use Batik (for generating SVG) > JM> and FOP (for generating PDF containing SVG graphics) this user is > JM> constrained to use the Batik version that FOP was compiled > JM> with. He cannot simply upgrade his Batik version to avoid a bug, > JM> for example. The very least he has to do is recompile FOP with > JM> that specific version of Batik he wants to use. Hopefully it > JM> compiles. To illustrate: > > Clearly having no interfaces change is a good thing, but we also > need to support SVG properly - the equivalent of this change was > _required_ to properly support SVG. It could have been done other > ways that (I think) would have preserved binary compatibility but they > would have had significant drawbacks on performance, maintainability > and robustness.
I understand. We have similar problems with the transition from maintenance branch to redeign. > FOP is a special customer and I am actually quite > surprised that you are creating subclasses of GraphicsNode (I > understand what is being done there but I could have suggested a > couple of 'better' ways to do it I think). Well, it's the way it is done now. It would be great if you could outline better ways to do what we need to do. > JM> As I said before, the FOP teams "produced" similar problems in the > JM> past. After a recent problem between Cocoon and FOP I'm committed > JM> to watching over FOP's APIs. I'm hoping that the Batik team will > JM> similarly watch over what happens in their APIs. > > So you are now committed to not introducing any binary or source > incompatibilities? I want to avoid them where possible. I want to help making sure that everyone thinks twice before changing an API. I'm not going to stand in the way of change. But we always have to be aware of our customers' needs. > I don't think Batik is in a position to do this > yet. I would say that when 1.5 goes final we might be willing to > offer that assurance for releases in the '1.5' branch. But we still > need at some point to support SMIL Animation I can guarantee you that > this will involve incompatible API changes/extensions/etc. Sounds to me like some problems could be avoided by separating non-interactive and interactive APIs. Like subclassing AbstractGraphicsNode to AbstractInteractiveGraphicsNode (which contains the getSensitiveBound() method). Just a thought, I'm not familiar enough with Batik. > >> BTW perhaps I'm missing the point of the 'maintence' build but > >> shouldn't that be done off one of the release versions of Batik? > > JM> I'm under the impression that Gump is intended to check > JM> code-compatibility between projects in CVS, not against released > JM> versions. This is to have an early warning about incompatible > JM> changes (before a release), so they can be resolved (hopefully > JM> with a compatibility layer) before the release. > > I guess as long as you can still make changes in the 'maintence' > branch it isn't an issue - but I would have thought that a particular > version of Batik would have already been targeted for the release of > FOP - rather than tracking 'HEAD'. It just seems odd to me that a > 'stable' version of FOP would track 'HEAD' on Batik. Not really stable. :-) The branch is more than 20 months old and has seen very active development. It's really two development tracks like Xalan 1 and 2. The older gets discarded eventually. > JM> With my findings above I think it would even make sense to have an > JM> additional mechanism to check binary compatibility (just some > JM> runtime tests using JUnit, for example) between projects (CVS of > JM> project 1 against release xy of project 2). > > Binary compatibility is really, really hard to ensure and I think > it only makes sense on 'point' releases, so 1.5 and 1.5.1 _should_ be > binary compatible, 1.5 and 1.6 may not be (and similarly 1.5b4 and > 1.5b5 do not need to be) - all of course IMHO - other Batik developers > may (and probably will :) disagree. Batik's in beta mode, FOP's in release candidate mode....for a very long time. :-) That basically makes each beta/rc releases quite important. But you're right, except that I would expect compatibility over a full version (1.x). I think you're missing my point about that idea: Testing a project CVS against dependent releases may be a good way to make a developer think twice (TM). That's basically the only thing I ask. Anyway, it was just an idea. Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
