On Mon, Mar 16, 2009 at 3:43 PM, Chris Little <[email protected]>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. 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. > > > 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. >> > > 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. > 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. > 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. > That sounds better for the moment than adding new testaments. But still I do not like to have this in. 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. 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. God Bless, Ben ------------------------------------------------------------------------------------------- Multitudes, multitudes, in the valley of decision! For the day of the LORD is near in the valley of decision. Giôên 3:14 (ESV)
_______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
