[sword-devel] Next Release

[Jonathan Morgan]

On Thu, Nov 27, 2008 at 9:22 AM, Troy A. Griffitts <scribe at crosswire.org> wrote:
>> Isn't this kept in SWVersion.currentVersion? Backward compatibility is
>> removed every new SWORD version, I think (not on purpose necesarily, but
>> there are always some things to fix.
>
> I don't believe this is true.  Although we add new features, sometimes
> changing object sizes-- which may prevent binary compatibility, not
> sure--  we try hard to maintain compile compatibility.  I would think
> that most old versions of frontends could compile on 1.5.11.  TRUNK is
> an exception because of the underlying requirement of dyn versification
> (dv11n) to not provide a static array of book name, chapter, verses any
> longer.  We should probably call this 1.6.0.

As it is potentially a big change in the way things work (certainly
from a user perspective, though maybe not from a software perspective)
I think you should consider making it version 2, and then use a more
standard version numbering system (saving minor point releases for
minor changes).

I also think it is worth strongly considering the comments from Jason
Galyon about packaging, and figuring out a sensible library versioning
scheme, following
http://www.tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN46.

Obviously I'm talking from the perspective of someone who doesn't have
to do it, but I think the following release structure should be
considered:
1. Minor bugfixes / efficiency improvements lead to near immediate
minor point releases (e.g. if the efficiency changes made some months
ago for compressed modules had been made while Sword 2.0 was the
current release, then it would be released as 2.0.1).

2. New filters also be released as new minor point releases when they
are implemented (I don't like the number of times we have a new module
that works but has to sit in beta waiting for a new release and then
new releases of different frontends - e.g. if there were Ruby filters
implemented when 2.0.2 was current, then a new version with just those
filters added could be 2.0.3, and the modules could depend on 2.0.3).

3. More major changes (don't know how we define this, but breaking API
and six monthly releases are probably good starts) become major point
releases (e.g. 2.0 -> 2.1).

If possible, we should try to maintain ABI compatibility for minor
point releases ((1) should, I'm not so sure about (2) - the above link
goes into detail about all the things that can break ABI for C++).  If
we can do that, then the library could be packaged under Linux as
libsword2.0.so.{0,1,2,...}, and thus new filters and bugfixes could
easily get to fontends without requiring their packages to be rebuilt
(on Windows we would probably still have to rebuild binaries, but
anyway...)

>>     2) stability: we are missing bounds checks for calls into the new
>>     VerseMgr, resulting in crashes if you, for example, ask for the max
>>     chapter of a book which doesn't exist.  I think this is the main cause
>>     for crashes, but it would be nice to get some feedback from the frontend
>>     developers of how stable the current code base is.  After a few days of
>>     hunting bugs and valgrinding, we can make a good decision if we should
>>     release without dyn versification.
>>
>> The dyn versification doesn't buy us anything (yet), does it? It still
>> lacks facility to map between different versifications, which is
>> crucial. That said, lots of people seem to want to read the apocrypha
>> with BPBible, so if it included support for the apocrypha that might be
>> different...
>
> Do you mean that that we don't include dv11n in this release because we
> don't get much (any) new functionality?  I guess I would answer that
> there are some improvements/optimizations, but my main purpose is to
> move forward and make it solid if we're close, rather than spend time
> separating these changes from other work which has been done.  Adding
> the layer of abstraction for dv11n is done and the first v11n system
> added is the old KJV system.  This should all be done.  We're not saying
> that we support dv11n yet, just that the new engine has the abstraction
> to support such and it would be nice to get this layer out in a released
> version, as a first stage, so we can test and assess things, while we
> work on the next stage.  I shouldn't quote this or I know it will be
> used against me, but "release early, release often" :)

I'm not sure "release early, release often" means releasing
development versions (as they sound like they are) as production
ready.  I personally would feel safer if the next release did not have
dv11n, but I can't be sure whether my feeling is justified.

Jon