Re: [XBoard-devel] lots of changes in git

[h.g. muller]

Some remarks about the numbering system and tagging:

When you bump the version number, could you also update the 
PACKAGE_FILE_VERSION?
This should be 4 16-bit integers, but that could still accomodate numbering 
like 4,2009,11,22,
which would seem good for 4.20091122.

I am not sure about the desiability of having intermediate tags like 
4.4.2.20091122 for 4.4.pre2
versions in the 4.4.x branch. This branch should only contain complete 
patches for fixing
small bugs that allow risk-less fixing. That means in principle that any 
git version there is
as good as any other. If we want to invite more intensive testing at some 
point by providing
a tar ball, we should simply tag it 4.4.x, and release. Because 4.4.x is 
still rather new and
involved massive changes, we are still getting bug reports at an unusually 
high rate, but
I am pretty sure that will slow down to a trickle at some point. (That was 
the whole idea
of introducing the 4.4.x branch, to be able to converge to a high-quality 
stable version
without new developments continuously introducing or exposing new bugs.)

So eventually we will probably tag every commit to the 4.4.2 branch as a 
new release.
Or we should distinguish major bugs (like absense of the WinBoard sources, 
or wrong
castling rights on FEN pasting) from minor bugs (a deprecated menu not 
working properly,
or crashing while already exiting on a fatal error) or cosmetic changes 
(removing superfluous
debug messages), and only tag and do a new release for every major bug we fix.
In practice we could hold up a release for a short time if we are working 
on fixing a few
minor bugs and know that we will be done with that within a reasonable 
time. (Say one week).

So I think what we should really do now is commit the forgotten pixmap 
patch for the opaque
details of the leaky fairy pieces, and do an official 4.4.2 release. If 
people come with
complaints on what we have in git now, the fixes will be for 4.4.3. The 
pixmaps patch
in itself should be no reason to release a new version (it qualifies as 
cosmetic), but
because we already have it waiting, it makes sense to include it in 4.4.2 
rather than save
it for 4.4.3. The same holds for the build problem just reported by Vincent 
Legout.

But I don't want to build in time-out periods, where we would only release 
after we
have not received new bug reports in a specified amount of time. That makes 
no sense
when bug reports will be arriving with Poissonian statistics at a fixed or 
slowly decreasing
average rate, which they will if the patches we make will not introduce new 
bugs.
Such a time-out period only makes sense if you think you might have 
introduced new bugs,
and people need to be given some testing time to discover them. But patches 
in 4.4.x
should not do that, and the only bug reports we should expect are for bugs 
that already
manifested themselves in 4.4.1.