[sword-devel] [sword-support] deuterocanonical support

[Greg Hellings]

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
>> committed...)
>
> 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
moniker.

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
guiding reasoning.

--Greg