[sword-devel] How broadly do we define "API" (was: Re: which engine sources to use )
greg.hellings at gmail.com
Tue Jun 9 20:18:11 MST 2009
On Tue, Jun 9, 2009 at 8:59 PM, Jonathan Marsden<jmarsden at fastmail.fm> wrote:
> Troy A. Griffitts wrote:
>> 1.6.x has been dubbed a non-API-breaking/binary-compat stable branch. If
>> you want to call that a bug-fix branch, great. We are in a phase of
>> development currently which doesn't require a branch. We are fixing
>> bugs, optimizing, and improving filter support, etc. These are all
>> things which will be released in the 1.6.x thread of releases. As soon
>> as we decide we need to commit something that breaks API/binary
>> compatibility, then we'll branch 1.6.x and continue 1.7.x on HEAD.
> OK, that is fine at the library API level, and is good news :)
> At the level of utilities that are used in scripts, and whose command
> line parameters are therefore in some sense an "API" for those who write
> scripts using them, the very recent (post 1.6.0) change to osis2mod that
> adds the -d option *already* broke "osis2mod API compatibility" :)
> I'd consider that kind of change an enhancement, rather than a bug fix.
> So even though I thought it was useful, I left it out of the SWORD
> 1.6.0+dfsg-1 packages...
I know the question has been raised before about separating utilities
from the library but nothing has ever shaken out of it. To me, this
again makes sense in this category. If the utilities were placed into
their own SVN repository they could easily be released on their own
schedule with their own requirements. An svn:externals could force
the source to be included with an SVN checkout of the library, but
could allow the utilities to be conceptually "operated" as a set of
highly specialized front-ends (which is really what they are) for the
library and released on their own schedule.
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel