[Uim] Towards 1.0

[YamaKen]

At Sat, 6 Aug 2005 01:28:35 +0900,
tkng at xem.jp wrote:
> 
> On Fri, 05 Aug 2005 11:27:41 +0900
> YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> > At Wed, 3 Aug 2005 03:34:55 +0900,
> > tkng at xem.jp wrote:
> > > * In 0.5 series (Sep to Oct 2005, hopefully)
> > > 
> > >  - Introduce SigScheme
> > >  - Improve key event handling. This will need extension of libuim
> > > API.
> > >  - Improve inter process communication.
> > 
> > I strongly recommend deferring the latter two features to next
> > development season (aka 0.7).
> > 
> > Since considerable amount of Scheme codes of uim do not have
> > testsuites to ensure valid execution, it will be achieved by
> > hands and eyes of users and developers. To limit number of
> > doubtful factors causing bugs in such situation, code changes
> > other than SigScheme migration should be minimized.
> > 
> > Yes, the two features themselves are not so complex. But they
> > may cause combinational explosion of doubtful codes by involving
> > the SigScheme migration. I prefer strengthening quality
> > assurance by the conservative development way.
> 
> SigScheme and other other big change will not be introduced at the same
> time. For me, this seems safe enough.

Separating big changes from each other by time is a good
practice. But it's insufficient without a release cycle.

A stable release is required once the migration to SigScheme has
done, to validate all behaviors of all IMs on all platforms are
kept. Since considerable amount of scm/*.scm does not have
testsuites, only hands and eyes of users and developers can
validate it.

+---------------------------------------------------------------+
| Releasing a stable uim is the only one method to call for     |
| sufficient number of the hands and eyes. Otherwise it will be |
| insufficient.                                                 |
+---------------------------------------------------------------+

If we avoid the release cycle before introducing consequent new
features that modifies preexisting codes, distinguishing the
factor of a bug will cost us annoyance.

I prefer the assurance.

> If SigScheme is unstable, then I'll cancel merging SigScheme
> on 0.5 series.

No, no. What I worried about is not SigScheme stability itself.
The most doubtful factor is the insufficient R5RS compliance of
Scheme codes of uim (i.e. scm/*.scm) that have no
testsuites. For instance, rk.scm has the problem.

We already have the two major unstabilizing factors, SigScheme
stability and R5RS compliance of scm/*.scm. So I simply don't
want more than them in a stable release.

I prefer the assurance.

> Big change moving to 0.4.x is not desirable for me, because after 0.4.8
> final, 0.4.x will be maintained as stable.

Okay, such changes should be deferred to 0.7.

-------------------------------
YamaKen  yamaken at bp.iij4u.or.jp