[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] GNU Go 3.2

From: Gunnar Farneback
Subject: Re: [gnugo-devel] GNU Go 3.2
Date: Thu, 25 Apr 2002 21:00:20 +0200
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Dan wrote:
> GNU Go 3.2 has been released at and in the CVS
> at The CVS release tag is rel-3-2.

This of course also means that it's time for a new development series.
Patches for 3.3.2 are welcome (3.3.1 has already been used).

Inge wrote (on March 24):
> I think it would be a good idea if we could try to make the quick
> release of 3.2 that Dan is planning and then try to limit ourselves to
> tuning and improvements of the connection handling until then.

Unfortunately, almost everything interesting we need to do with
connections are likely to destabilize the engine substantially.

> Then, after the olympiad we could start with new exiting ideas. That
> way we might make as good a result as possible in the competition.
> What do you think?

It's true that it would be good to have a strong and stable engine for
the tournaments, and preferably improved compared to 3.2. But limiting
development to tuning and simple code modifications for another couple
of months seems too restricted.

Instead we'll (probably) do like this:

The development starts with the 3.3 series. When potentially
destabilizing patches start to appear we split off a 3.5 series. The
main development then takes place in 3.5 and sufficiently safe changes
get merged back to 3.3, possibly after some time of testing and
maturing in 3.5. The aim of 3.3 is to be a more conservative
development branch from which we can at any time pick a version for
use in a tournament. After the tournaments are over we close the 3.3
line with a stable 3.4 release.

As a consequence of this, if you have multiple patches already
prepared or is choosing between different things to work on, start
with the least risky ones. It's an advantage if we can get in simple
changes before the split, since it reduces the amount of work
required. But don't let this stop you from sending in less
conservative patches as well, if that's what you have.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]