Frank Heckenbach wrote:
Conclusion (as far as I'm concerned):
Never make a release under pressure anymore. (Everyone, if you want to tell me why a new release is urgently needed at any time, please redirect to /dev/null.)
Never do post-release updates, even if serious bugs. (Except perhaps for the proposed alpha/beta scheme.)
Frank, I was surprised that the updates have the same version number as original release, and that is the repeating complaint. I do not know what your release scripts do, but AFIKS just renaming tarballs and the main source directory would completely avoided any confusion. If done by hand, such renaming should take no more than one hour work (that is conservative estimate, assuming that you would have to manually transfer files and type in passwords and then fetch back the release to check it). I estimate that such renaming would take less time then answering resulting e-mails.
The point is: never change a release, it is much better to fake a new release (if you want to avoid your normal release procedure).
Frank, please do not take that remarks too personally. You are doing very good job maintaining GPC. This is just a little detail in contrast with "best practice". And had you wrote "I will rename the relase" I would not write this message.
echo "I would be nice to have a new relase (even if it contains" \ "nothing new), just to make clear that all stale copies of" \ "gpc-20030830.tar.gz are obsolete" > /dev/null