Glenn,
I see the IF API as an advanced use case for FOP. I've realized from the
beginning that the IF might have to mature over time and that requires
changes. My main concern in the whole discussion is stability for the
large majority of FOP's users who just rely directly or indirecly (in
the case of XML editors and such) on relatively easy upgrades,
especially if FOP can one day be released more often (with an easier
release process).

Just a thought loosely related to this: maybe we should introduce a
"version" attribute on the root element to indicate the version of IF
XML format so people can deal more easily with that.

Maybe there should be a registry of FOP's APIs and the stability policy
for each.

On 02.04.2012 17:15:58 Glenn Adams wrote:
> On Wed, Mar 28, 2012 at 12:08 PM, Jeremias Maerki 
> <d...@jeremias-maerki.ch>wrote:
> 
> > There must be a really, really good reason to change the frontmost
> > public API of FOP in a backwards-incompatible way. Changing the API will
> > cause considerable work for all users when they upgrade. We must not do
> > that on a whim.
> >
> 
> Would you consider a minor, but substantive technical change to the IF
> APIs, specifically, to IFPainter, to require a revision of the major
> version? I ask this because one of the arguments to IFPainter.drawText()
> has been changed from int[] to int[][] in the recent complex scripts merge.
> 
> In other words, are the IF public APIs to be considered part of the formal
> public FOP API that is subject to version control rules?
> 
> Do we have a precise list of which APIs are (or should be) subject to such
> rules?




Jeremias Maerki

Reply via email to