On Mon, May 02, 2005 at 03:58:20PM -0700, Justin Mason wrote: > > OK, I do not agree with this. in my opinion, a release number is only > "burned in stone" once the file is announced, uploaded to CPAN, etc. > I'd prefer to avoid "burning" too early, as it makes for less flexibility. > > What if a bug is found in those prerelease tarballs? We move onto > 3.0.(x+1) without issuing 3.0.x, immediately? That's (a) messy, (b) ugly, > (c) will cause confusion among users and packagers, and (d) is > unprecedented either in *this project*, or others.
Respectfully disagree. Once a release has been rolled, heck once we've checked in the uncommented IS_DEV_BUILD SpamAssassin.pm and Changes file, then it's out there and effectly released and available. If you come back later and update a file or make a change and re-release you'll never know if someone has the old release or the new one. Version numbers are cheap, might as well use them. We're an open source project, we should be releasing more often and earlier. Setting things up so that anyone can declare a proper time to release and then going off and doing it helps with that policy. If a release has a problem, you scrap it and move onto the next. It's a widely accepted practice for other Apache project, such as APR and Httpd. I really wish I could find the original thread when Greg Stein proposed it, it was really well thought out and put things in the right perspective. Why should we be afraid to skip a release? Folks only care what the latest is, not that they missed one. > Let's not make rules for the sake of making rules! Like I said, several other Apache projects follow the same release guidelines. Michael
pgpJvR4JPD2eo.pgp
Description: PGP signature
