[sword-devel] Announcing Sword++

[Troy A. Griffitts]

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