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 _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
