>>>>> "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. 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).
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 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.
>> 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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
