[sword-devel] SWORD releases and 1.8.x

[Troy A. Griffitts]

Dear CrossWire Community,

As you all know, we have been negligent to push out an official stable
release for a while, and thus many of us, myself included, have been
building against SVN trunk for our projects.  This is not what we have
hoped for.  In this email, I will very briefly describe the events that
brought us here and what we've done over the past weeks to try to
rectify the situation moving forward.

For many reason, both external to CrossWire and internal, and beyond the
scope of this email, our release management lost track of which commits
were ABI-compatible bug fixes which could still go into the 1.7.x
branch, and thus the 1.7.x stable branch releases ceased.

The past few years has also seen the end of my academic education,
culminating in a 300+ page deadline of Aug 31 of this year.

Months before this deadline, understandable restlessness for a release
prompted me to attempt to solve the situation with a compromise: taking
trunk, as-is, and pushing out a new stable ABI-locked branch 1.8.x.  We
came really close but with each release candidate, very small but
important patches (build fixes for various distros, security concerns,
etc.) were sent in against the RCs (thank you everyone!) and as my
deadline loomed, living on no sleep and coffee, I just couldn't manually
push out another build, hence the "few weeks delay for personal reasons"
email back in August.

Now that school is entirely finished for the rest of my life and things
have settled down for a bit, and prompted by gentle reminders from many
of you, all parties involved in release management have gathered and
agreed upon a plan to restore normal releases moving forward.

Greg Hellings has agreed to own release management with the stipulation
that he is able to setup an automated CI environment on our server to
help him manage the process.  DM Smith and Greg have agreed on Jenkins. 
DM and/or I will install the necessary RPMs on our server for this
happen.  Greg does this work daily at his job at RedHat, so this should
not be an ordeal for him to setup and configure.  In the mean time, I
will manually push out what we hope will be our last manual package, new
1.8.0 RC, appropriately on Halloween.  In the few days it should take
Greg to setup the automated release infrastructure, we can get feedback
on the RC.  Once the automated release infrastructure can build a
release, I would like 1 more RC from the automated system, to include
any patches for anything found over the next few days, and to also
assure that nothing adverse has come about with the automated release
process, and then if that first automated RC looks good, we will
release-- I wanted to use both Halloween and Thanksgiving as appropriate
dates, but I also hope the final release will be weeks before Thanksgiving.

Now having a couple weeks of time, school-free, I have been able to
commit what will make the 1.8.x stable branch more of what we usually
consider as reasons for cutting a new ABI-breaking branch (jumping from
1.7 to 1.8), so it isn't merely a compromise release to get release
management in sync with development.  I have done a full optimization
pass, which we nearly always do just before cutting a new branch.  You
should notice considerable speed improvement, primarily in filter
processing, which gives returns for many aspects of the engine,
including index-less searching.  I have also done our usual
normalization of method names, this time in SWConfig and SWMgr, as we
always do in a new branch in our march toward complete normalization for
2.0.  Of course all 1.7.x method names remain for backward compatibility
and will remain until 2.0.   I've had a chance to go through many of the
bindings and bring them up to currently supported status, including the
java-jni, android, and cordova plugins.  All of these changes over the
past few weeks has brought what was a compromise 1.8.x branch up to
something which we can comfortably say warrants a jump from 1.7.x to
1.8.x (of course in addition to all the great new features you all have
contributed over the past couple years, including new v11n schemes,
inter-v11n translation, new LaTeX filters and many other things I know I
will forget-- please forgive me).

Thank you to everyone who has patiently contributed and my apologies to
everyone for needing to build against trunk in the absence of a
maintained stable branch.  I hope this plan brings a solution for
regular stable releases to our community, moving forward.  Thank you to
everyone who has pitched in to help solve this process malfunction and
especially to Greg Hellings for committing his time and perfect talents
to own release management moving forward.

In Christ, as always,

Troy