(Illustration by Gaich Muramatsu)
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.Received on 2007-08-12 07:38:41