[Uim] Towards 1.0

[YamaKen]

At Wed, 10 Aug 2005 04:37:34 +0900,
tkng at xem.jp wrote:
> 
> On Tue, 09 Aug 2005 07:32:54 +0900
> YamaKen <yamaken at bp.iij4u.or.jp> wrote:
> 
> > 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
> 
> IMHO this phase should be done in r5rs branch.

No. What I intended by 2) is not the SigScheme migration itself
in r5rs branch but merging it into trunk.

Yes, it will cause no problems within an ideal situation. But as
you already know, my pessimistic thought distinguishes the two.

The words "the merger has become roughly stable" is supposing
about resolving conflicts, logical code glitches, unexpected
duplicated lines caused by excessive or incomplete diff lines
passing between the branches until the time, etc.

But I'm not requesting a paranoiac process. What I want by 2)
are simply defined as:

- merge r5rs branch into trunk
- check that the trunk is working as same as latest r5rs branch
- release an unstable release from *trunk* (not from r5rs)

> > 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
> 
> I agree basically.

Thank you.

> I have one question. 3) is intended to be only be a origin of
> new composer branch? 

No. 3) is needed for all people, to judge whether a bug came
from the SigScheme migration or not.

1) and 3) are expected as:

- 1) will become the most stable code before introducing
  SigScheme. It is a "reference point" ("kijun-ten" in Japanese)

- 3) will become the mostly stable code based on SigScheme. It
  is another "reference point"

If you release the 1) and 3) as I suggested, any people can find
where a bug came from, when an user find a buggy behavior on the
trunk beyond 3). I refer this point as 4).

- If 1) shows the buggy behavior, the bug ware hiding before 1)

- Otherwise, if 1) does not show the bug and 3) shows, the bug
  came from the SigScheme migration

- Otherwise, if 3) does not show the buggy behavior, the bug
  is inserted between 3) and 4)

Comparing a behavior between some reference points is a popular
and efficient method to locate a wrong point ("shougai no
kiriwake" in Japanese).

> If so, I think trunk freezing between 1) and 2) is sufficient.

In addition, 2) is intended to be tested by active users
enough. And of course stability feedbacks from them is also
intended.  So I insert the interval (10 days - 2 weeks) between
2) and 3). The interval gives them one or two weekend to examine
it.

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

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