<br><br>
<br><br><div class="gmail_quote">On Mon, Mar 16, 2009 at 3:43 PM, Chris Little <span dir="ltr"><<a href="mailto:chrislit@crosswire.org">chrislit@crosswire.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Ben Morgan wrote:<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Mon, Mar 16, 2009 at 10:41 AM, Chris Little wrote:<br>
<br>
<br>
<br>
Barry Drake wrote:<br>
<br>
Hi Chris .......<br>
<br>
Chris Little wrote:<br>
<br>
We plan to have this ready for our next release<br>
<br>
This is the most fantastic exciting news. I've been carefully<br>
following all Troy's and your recent svn commits. Thanks for<br>
all the great work.<br>
<br>
<br>
It's all coming along very nicely, and I should be able to make an<br>
announcement and post some example content using a non-KJV<br>
versification "Real Soon Now".<br>
<br>
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...)<br>
</blockquote>
<br></div>
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.<br>
<br>
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.</blockquote><div>But the whole point of 1.5.12 was to be a quick bug-fix release - surely we can leave a big feature like that for 1.6.0/2.0? And anyway, it isn't really properly finished, I don't believe.<br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A major problem with alternate versification is there currently isn't any way to map between different versification schemes - which is very important for parallel views, etc. Also, quite a lot of code assumes things like 2 testaments - I'd like to give these a little time to migrate.<br>
</blockquote>
<br></div>
As has been mentioned, there are no plans to address mapping between v11ns in the first release. That will come later. It's important, but not as important as simply supporting other v11ns at the most basic level, which will allow basic display, lookup, search, etc. Besides, we don't support mapping between v11n systems at the moment for Bibles from different v11n systems that have been wedged into the KJV system.<br>
</blockquote><div></div><div>That's true, I suppose. But I'm afraid that once different v11n systems are available, lots of material will be created using them which is missing out on mapping completely - some of which may never then get it. This is why I would like to have it presented as a complete fix. <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The 2 testament system will remain and there are no plans to change that. We're not going to add additional testaments. We'll simply contract or extend them, as necessary, for a given v11n. Testaments are primarily an issue of storage location since each testament gets a separate set of files. The only other significant aspect of testaments is that they host a testament introduction. At present, I'm simply assuming that the NT begins with Matthew, so all preceding books are in the OT and all following in the NT. Thus, if deuterocanonicals appear following the OT books, they will be included with the OT, and if they appear as an appendix after the NT, they will be included with the NT.<div>
<div></div></div></blockquote><div>That sounds better for the moment than adding new testaments. But still I do not like to have this in.<br><br>I still think too much code is assuming (now) flawed assumptions - that VerseKeys can live by themselves, for example. I know BPBible creates a lot of versekeys and assumes that it can construct one from another by merely setting the text. It also keeps other data around about the shape of the canon. I don't want this broken in a minor point release of the software. It will be even worse if the number of verses in chapters, and things like that change. This could be disastrous.<br>
<br>I think that if you allow creation of books in different v11n systems it will break lots of code. So I think that a release 1.5.12 should be quickly released which does this. Otherwise I am going to distribute BPBible 0.4.1 with Sword SVN, patched. And I'd rather not do that.</div>
</div><br><br clear="all">God Bless,<br>Ben<br>-------------------------------------------------------------------------------------------<br>Multitudes, multitudes,<br> in the valley of decision!<br>For the day of the LORD is near<br>
in the valley of decision.<br><br>Giôên 3:14 (ESV)<br>