Hannu Krosing writes:
> You could also consider the above as an IQ test ;)
The only problem is that computers have been shown to have an IQ of zero.
> I suggest that you do a writeup of yours, enumerating the rules for
> both internal (code and CVS tags) and external development, alpha,
> beta and release numbering and naming as well as rules for when and
> how to apply them.
The rules have been the same for as long as memory serves. The
development tree is first labeled as betaX for a few consecutive X, then
rcX a few times, then follows a release, and the numbering scheme of the
releases is well known. We've more recently introduced labeling the
development tree itself as "devel".
The problem appears to be that the people that perform these actions do
not fully understand the scope of the issues the come with those actions,
and therefore perform them carelessly. (If you don't believe "careless",
the commit message that changed the version to 7.2b1 is less than one line
and contains two obvious spelling mistakes.)
For example, release numbers ought to sort lexicographically. There are
just too many tools that would prefer this. Yet, this issue is ignored
completely.
Release making should be reproduceable -- without race conditions. This
would at least require a CVS tag for every release, and a reliable way to
package the documentation with the rest of the source.
People need to understand the meaning of the release names. There are
obviously way too many release numbering schemes out there, few of which I
like. But in the history of PostgreSQL, there has never been a release
called X.Yb1. I have currently no confidence that the next release won't
be called X.YBeta2, to mess up all chanced of anything sorting correctly.
In a sense, making a release is a change in the source code, and if it's
done in novel ways it should be discussed first.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter