[Uim] Towards 1.0

[YamaKen]

Hi Hiroyuki, let's find our best compromise to conclude the
discussion.

At Sat, 6 Aug 2005 04:34:52 +0900,
tkng at xem.jp wrote:
> 
> On Sat, 06 Aug 2005 03:14:35 +0900
> YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> 
> > > > >  - 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).

> > 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.                                                 |
> > +---------------------------------------------------------------+
> 
> That's one insight, but I don't think so. IMHO the number of testers
> depends on the degree of activity of developers. I believe that if I
> reply bug reports quickly, we will be able to get enough testers.

I think that it's true about active contributors. And your
recent efforts are actually attracting them.

But many stable-followers are also existing. They are
distributed in broader platforms and will report minor
problems. For example, FreeBSD ports collection only contains
stable version of uim. And external projects such as uim-prime,
MacUIM and mlterm may only follow stable (or near-stable)
versions. So I suggest a stable release.

Please keep in mind it whether you select which development way.

> > 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 understand, but 'In this stable release SigScheme was introduced, but
> nothing other was changed!' would not be attractive for users. They
> would not want to upgrade to such new version.

I think it worth. But since you had already started the
development of the message bus facility on the trunk, I change
the suggestion as follows. Would you think it reasonable?


I only want 3 sequencial unstable snapshot release from 0.5
around merging the r5rs branch, as follows.

1) Make an unstable release from 0.5 series immediately before
   merging r5rs branch into the trunk

2) Make another unstable release from 0.5 once the merger has
   become roughly stable

3) Make more another unstable release from 0.5 at 10 days (or 2
   weeks if patient) after from 2).

The trunk must be kept unchanged other than r5rs branch merging
through the days between 1) and 3). This is required to reject
unstabilizing factors came from other than the SigScheme
migration.

Expected benefits are:

  - The two milestone releases 1) and 3) will become reference
    points to be compared with subsequent 0.5 series about its
    behaviors, to locate where a bug comes from

  - 3) will become new origin which the composer branch based
    on. I'll forward-port it to the branch

  - Because releasing an unstable snapshot costs lower than
    stable one, it is an efficient assuarance

I don't persist about what should be developed in 0.5 series if
you accept it. The trunk is your field.

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