[bt-devel] Fwd: [sword-devel] Sword release roadmap suggestions

[Martin Gruner]

Hi folks,

This is the sword release draft for the next version(s). I guess there won't 
be bigger changes to this.

Now my suggestion for BibleTime: We should release 1.1 as soon as possible 
with the open bugs fixed and a few minor features added. The documentation 
rearrangement and translation will take the most time here, so we should 
probably enter message freeze as soon as possible. 1.1 will depend on sword 
1.5.3.

1.1 will be the last major version before KDE3. Once KDE3 final is out we 
should quickly port and do the necessary changes (e.g. new font handling, 
printing) and release 1.2 as soon as possible without new features. Then we 
can enter the normal development again.

Martin


Sword release proposal follows:

----------  Weitergeleitete Nachricht  ----------

Subject: [sword-devel] Sword release roadmap suggestions
Date: Mon, 22 Oct 2001 09:55:30 -0700
From: "Chris Little" <chrislit@chiasma.org>
To: "SWORD Devel List" <sword-devel@crosswire.org>

I want to discuss our release roadmap for the next one or two versions
of Sword & BibleCS and what should be included in those releases.

I think we should go ahead an do a 1.5.3 release of both Sword & BibleCS
this week or next.  I think these should include only the functionality
currently in CVS with bug fixes if necessary.  (The ICU stuff &
right-to-left changes in the new BibleCS alpha are not completely in
CVS, and should be left out of the next release I feel.)

Sword 1.5.3 would include things like swbasicfilter & its descendants.
The current Latin1UTF8 filter.  The UTF8 filters for removing Greek &
Hebrew diacritics.  As well as simplified support for big endian
architectures like PowerPC & SPARC, and anything else I've forgotten.  I
wouldn't recommend that anyone turn ICU support on for 1.5.3.

BibleCS 1.5.3 would include few features from Sword.  The UTF8 filters
are all I can think of.  But they would include all of David Trotz's
work on schemes, the splash screen, the daily devotional screen, etc.

After releasing 1.5.3, I think we should target a late November release
of 1.5.4 (but not sooner than ICU 2.0 is released).

One major aspect of 1.5.4 should be official support of ICU, meaning
icu-sword should also be released and and front-end authors should feel
free to make use of the UTF8Transliterator filter.

The other major aspect of 1.5.4 will be moving much of the functionality
that gets repeated in all front-ends back into the API.  Rather than
creating their own encoding & markup filters (GBFHTML, Latin1UTF8,
UnicodeRTF, etc.), front end authors will simply tell SWMgr which
encoding & markup they desire and it will handle any necessary
conversion for them.  This not only simplifies front end creation, it
allows addition of new formats to the library without requiring any more
than a recompile.

I think we will be subclassing SWMgr to add all of this.  I have the
encoding portion started (and working in the new BibleCS alpha).  And
Tom Wildsmith, who just joined sword-devel, submitted a patch that
handles the markup portion.  What timing. :)

BibleCS 1.5.4 will incorporate all this Sword 1.5.4 functionality and
hopefully add correctly functioning right-to-left support for all
versions of Win32.  That doesn't preclude addition of HTML rendering,
printing, etc. if people get ambitious. :)  In fact, HTML rendering may
be a precondition for correct right-to-left support.

Something I would like to see before we get to Sword 1.6.0 is a
switchover to UTF-16 from UTF-8/Latin-1 for all internal processing.
This will speed up all ICU calls since they won't need to do UTF-8 to
UTF-16 to UTF-8 conversion and should speed Win32 & WinCE for the same
reason.  Most of all, it simplifies searches and other internal
character processing.  I don't see much advantage to UTF-32, even though
we already have one module that uses characters that need surrogate
support (characters outside of Unicode Plane 0, > 0xFFFF, that need 2
16-bit values in UTF-16).  This is a big change, though, and will
require breaking most of our filters as we convert them to use 16-bit
values instead of chars.  UTF-8 output will still be supported, of
course.  And I have no plans to support UTF-16 encoded modules because
either SCSU or UTF-8 should always encode them using equal or less space
and the byte-order issues raised by UTF-16 encoded file would just cause
performance problems on some platforms.

--Chris

-------------------------------------------------------