Yes, that looks like a better plan.

Please just set version to e.g rpc2-2.6.90 (for beta), or if you must
rpc-2.7rc1, so that packaging systems that are used to those conventions
don't have to learn yet another flavor-of-the-month in naming/sorting.
<rant>Long ago, the GNU project had a version number scheme, and it was
sufficent.  Now, for no good reason, there has arisen rc, a, b,
prerelease and a lot of other things.  Note that the GNU scheme didn't
require anyone to understand it to do the right 'earler?'
comparisons.</rant>p

I realize you don't want packaging systems to be actually updated -
that's the point, but the packaging systems need testing, and IMHO the
way to do that is to do the update to the rc version and not commit it.
For minimal kludge, this means that the version# in configure.ac should
have the .90 or rcN suffix, so the version and the directory name in the
tarball match.  "prerelease" seems to be something that is a release,
just not declared, and claimed internally to be the release version,
with the release directory name.  I don't think coda needs that, and it
in my view causes way more trouble than it is worth.  Maybe you didn't
mean that, but I just had grief with that someplace else.


Also I'd suggest:

  publicizing where the cvs commit list is so people can subscribe

  sending a note to codalist whenever anything signficant has been committed to cvs

  not cutting an rc the day after stuff that might break long-working
  functionality goes in to cvs

  if the anoncvs people can check out from isn't the real repo (or a
  copy of it for security reasons), explain what's going on.


I was caught by surprise by the previous release, and the
automakification.  I was glad to see it, but hadn't even tested it on
NetBSD before the release.

I wonder if this is why my machine was not happily communicating with testserver.