Hi Jaak and others,
Karl is right, we haven't had an official release since 24-Dec-2014,
which is way too long (there is a 1.7.5a1.tar.gz bundle out there dated
Aug-2015 but I'd have to talk with Greg to see what that is). This
delay is in part due to my deficiencies in adequately marking for our
release manager my commits which are considered bug fixes against other
commits which break binary compatibility and should stay unreleased
until our next major release, and also partly do our release manager
being preoccupied and I haven't given him relief by doing it myself or
finding a temporary release manager. But we've always had long release
cycles and that always falls back on me. I am sorry.
Jaak, I wish you the best in your endeavors. We obviously have clearly
different objectives. I would prefer libsword to have the ability to
compile and run efficiently on a toaster or any other device on which
someone might want to pop up a Bible verse-- now or in the future, and
you have stated very specifically your primary objective is to support
Bibletime on 64bit Linux machines. My path to meet my objective is to
be as minimalistic as possible, avoiding dependencies and language
features which might not be present except on fully compliant, modern
compilers, and can compile on most any device we've tried over the past
20 years with very little effort, and you would like to use the newest
language features. I truly wish you the best.
I can foresee a few problems for Bibletime not basing development on
libsword, one primarily being that the software will need to discern the
distribution rights of the module repository, if you still plan to point
Bibletime to CrossWire to obtain modules. I'd like to support you the
best we can and that probably means that we need to release a lower
level bundle of possibly C-only code which can access our binary format
and let you base your development on that. This will still, in name,
allow you to say you are using the SWORD library and still have legal
access to modules which have distribution rights granted to CrossWire.
We should spend the time to do this for you; otherwise, your software
will need to be aware of which modules are freely distributable and you
are certainly welcome to have your users download those from our server.
Peter and I spent some time together a few weeks ago working toward
cleaning up our dev branch preparing for a release, but we still had a
few outstanding items to clean up with regression tests, a warning about
directory trees with newer versions of autotools, an osis2mod item to
talk about with DM, including a few patches from IBT, and your latest
submissions, and rather than sift through which commits are bug fixes
and which break binary compatibility, we planned to simply release 1.8
and include everything in the dev branch once all is committed and it
passes regression tests. I return from my summer work here in Germany
in 3 weeks and hope to have time to do all this then, if not before.
Blessings in your work,
Troy
On 09/25/2016 11:19 PM, Jaak Ristioja wrote:
On 25.09.2016 22:50, Matěj Cepl wrote:
On 2016-09-25, 18:54 GMT, Jaak Ristioja wrote:
Sometime in May this year my efforts to improve the Sword
library as the backend for BibleTime led me to create branch
or fork of the Sword codebase, which I eventually called
Sword++.
Well, aside from the fear that it will kill any upgrades in most
Linux distros (I don’t expect many maintainers eager to maintain
two libsword* packages), no comments.
Why no comments? What do you mean by "kill any upgrades"? Sword++ does
not strive to be API compatible with Sword, because the API is something
I think that needs to be changed at least to some extent anyway. For
example we use the "swordxx" namespace instead of "sword", have
renamed/removed/added some classes/functions etc. And of course it will
be a new library: "libswordxx" instead of "libsword". Distros will not
have to deal with two different libraries having the same name.
Could you please elaborate on your fears? Personally, I'm not afraid nor
see any reason to be afraid. Foremost because I don't think packaging is
a hard task unless library developers make things difficult for
downstream by some non-standard practices. Second, I introduced Sword++
as being in very early stages of development. It was not a release
announcement. So we have some reasonable time to work out any details,
if we ever get to a release. We are considering using Sword++ instead of
Sword for BibleTime 2.12, just because it will (hopefully) be more
developer-friendly to use, more stable etc. I don't see a reason for
distros to reject newer versions of BibleTime just because it uses
Sword++ instead of Sword. Of course we need to communicate dependency
changes to packagers, but I don't think this will be a huge problem. The
alternative might be to bundle a copy of Sword++ with BibleTime.
Best regards,
J
_______________________________________________
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
_______________________________________________
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
