[sword-devel] [bt-devel] Compatibility break: Sword 1.6RC1->RC2 API change

[Jonathan Marsden]

Eeli Kaikkonen wrote:

> It is usual practice to mark some API features deprecated. It could have
> been done here, too. Better yet, why not let the setter function be (at
> the moment, put it back). ...

We both came up with more or less the same solution at the same time :)

> ... calling a library an RC should mean there are no more API changes
> unless they fix critical bugs. This one wasn't critical, not even a
> bug.

Indeed.

> And still one little issue: the version number was still 1.5.11.99, for
> both RC1 and RC2. It should have been pumped up to 100 (there's nothing
> wrong in using 100 as a version number!).

Since I was going to do this anyway, my own workaround for this is going
to be to only package 1.6.0RC2 so as to create libsword8 (in other
words, do the SONAME bump I was planning to do anyway but had not got
around to yet!).

> The bright side of this situation is, at least in my opinion, that the
> Sword library is growing in importance. Our practices and skills should
> just grow along with it.

Sure.  The length of time the SWORD library has existed may have given
me a too-high expectation of the maturity of its overall release
practices.  I hope I have only criticized those practices, not the
people involved -- we all make mistakes (as anyone who reads my bzr
commit logs can testify!).

For this particular API change (and perhaps also for the
sysconfig/sysConfig method name change) there is still time to make 1.6
backward compatible, and IMO doing so would be a very appropriate
resolution of this issue.

Jonathan