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 > <[email protected]>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
