[sword-devel] Why I think there should be a Sword 1.5.4
Wed, 2 Jan 2002 14:47:33 -0000
I'd agree with Martin. Any new features should go in 1.5.4 unless there is any
particualr reason Are there any important bugs or anything that need worked on
before 1.5.3 can be released? or is it ready at least for a 'beta' release for a few
weeks before a final release? (time to check for bugs and prepare the frontends for
Come to think of it, the new version of Debian is going into freeze very soon (hopefully
< 2 months, possibly 1 month). Whatever versions of sword/gnomesword/bibletime are
released at that point will be what goes into the release. Only bug fixes rather than
new version will be accepted.
With that in mind, let me know if there is anything I can do to speed up 1.5.3 being
On 23 Dec 2001 at 18:14, Martin Gruner sent forth the message:
> > I get the impression that our users and front end authors would
> > appreciate a 1.5.3 release to be sooner rather than later, in which case
> > I think we ought to plan on a 1.5.4 release.
> This is correct. We'd appreciate smaller and more frequent releases, which
> could be done by implementing some of the features below and making a smaller
> release (.4, .5 etc.). 1.5.3 could be released right now (from a
> feature-point of view).
> Things I leave uncommented should imho go into 1.5.4:
> > 1) i18n
> > 2) general book support
> Should probably wait to 1.5.5 or later, too big a change. Requires a lot of
> work in the frontends.
> > 3) expanded ciphering support
> > 4) apocrypha support
> Probably it would be better not to go 2 steps, but handle this with the new
> versification scheme handling, which would be much more flexible? It will
> require changes in the frontends anyway...
> So probably wait until 1.5.6 and be combined with versification.
> > 5) UTF-8 regex support
> > 6) bookmark interface
> This is not as simple as you might think. To make them shareable you must
> think about i18n() here too. You need to think about the versification stuff.
> And finally it might be good to have the data in XML to make it useful for
> other ppl too.
> So imo this could wait a bit. Probably until 1.7.x
> > 7) swtext++
> > 8) search on (currently) stripped items
> > Currently, Strong's numbers, morph tags, etc. are stripped out for
> > searches. There are of course circumstances where a person would
> > explicitly want to search for a given morph tag or Strong's number, so
> > we should make sure a facility for this exists.
> YES! It should be possible to search in each layer of text (base, stongs,
> morph, etc.) independently. This is not likely to be possible with the
> current approach, and might require a thorough change in the api, which would
> be good, but maybe too big a task for now. And while doing this, things like
> making the searches faster (realtime?, indexing) should be considered too. So
> this probably should wait too. Maybe 1.7.x.
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com