On Tue, Apr 3, 2012 at 1:54 PM, Jeremias Maerki <[email protected]>wrote:
> 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. > good idea; i will add > > Maybe there should be a registry of FOP's APIs and the stability policy > for each. > ditto > > 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 > >
