>
> I know it's tricky to have any sort of release road map for gnubg,
> as there are only a few developers coming and going and largely
> doing what they want, it's been a goal of mine for a while to get
to
> a "version 1" release though, so here's a plan that may
get us there...
>
> After the recent flurry of small changes I suggest we release a
> version numbered 0.90, then when we've done some more changes 0.91
> and so on for a few (one to three/four?) versions until we're happy
> enough that with everything to release a version 1.0. So it
might
> go something like:
>
> 0.90 current code
> 0.91 some 3d stuff and start on database reports + ...
> 0.92 other changes/bug fixes...
> 0.93 documentation (web site + help)
> 1.0 translations and bug fixes
>
> The idea being that version 1.0 is basically the current code with
> some features finished off/rationalised, which means that any large
> code rewrite or major change should wait until after version 1.
>
> It might be better to have a build number as well so version 0.901
> is the first build of 0.90 and then if any important fixes are
> needed we can have a 0.902 build, etc. Which would make it easier
> to check what code someone is using.
>
> Jon
I forgot at the time: can we merge the positionID
an the matchID into a single ID (being simlpy the concatenation of
the two, for backward compatibility maybe) ?
I find it extreeeemely annoying to have to copy/paste
twice ...