[sword-devel] [sword-support] deuterocanonical support
greg.hellings at gmail.com
Sun Mar 15 22:08:53 MST 2009
On Sun, Mar 15, 2009 at 11:43 PM, Chris Little <chrislit at crosswire.org> wrote:
> Ben Morgan wrote:
>> On Mon, Mar 16, 2009 at 10:41 AM, Chris Little wrote:
>> Barry Drake wrote:
>> Hi Chris .......
>> Chris Little wrote:
>> We plan to have this ready for our next release
>> This is the most fantastic exciting news. I've been carefully
>> following all Troy's and your recent svn commits. Thanks for
>> all the great work.
>> It's all coming along very nicely, and I should be able to make an
>> announcement and post some example content using a non-KJV
>> versification "Real Soon Now".
>> Can I please plead not to have this in this release? Please? I want to
>> see a release. Currently trunk seems relatively stable for usual modules,
>> so I'd like to see a release (once a couple of patches of mine have been
> I guess I don't see the logic to postponing a new feature that is much
> desired and adds a lot of capability, considering that it is basically done
> and shouldn't require very extensive testing. I say that it shouldn't
> require much testing because the KJV v11n is now using the same kind of v11n
> plugin system as we plan to use for non-KJV v11ns.
> The new v11n architecture is the biggest new feature of 1.5.12, and I think
> finishing its implementation represents a sufficiently significant milestone
> for the release of 1.5.12.
Can I beg, just as heartily, that you NOT call this release 1.5.12?
As I've mentioned before, if you call something that has changed from
a Protestant-only canon to an all-Christendom canon only a sub-minor
version update, then it feels to me like you've got absolutely nothing
else that COULD qualify as a more major update. It also breaks the
API of programs building against the library to go from 1.5.11 to
HEAD. A change from 1.5.11 to 1.5.12 should not signify a massive
shift in the library's primary display content methodology (Bibles) as
well as API-breaking changes -- sub-minor versions should be bug fixes
and non-API changing technology. Something as monumental as
deuterocanonical support should warrant, at the very least, a 1.6
If not 1.6 or 2.0... then could you possibly explain to me the rhyme
or reason given to the versioning system? I presume that the two-dot
notation means that the numbers are not simply indicative of
chronological ordering, otherwise you'd use something like the Ubuntu
numbering scheme. What constitutes a major, minor and subminor
version update? I realize there's probably not a hard-and-fast rule
which must always be obeyed, but certainly there should be some
More information about the sword-devel