To generalise, packagers like Project Releases (and developers don't like releases) because:
DGP I think names/versions like YYMMDD do suffice, but cvs snapshots don't have such names automatically. Consider Tcl's core-8-4-branch. If you get a snapshot today, it claims to be version 184.108.40.206. If you got one last week, it also claimed to be version 220.127.116.11, even though the code has changed in that week. And Tcl is one of the better projects about at least distinguishing the version numbers of actual releases from CVS.
It's been an interesting argument, and points to a fundamental tension between the goals of the two groups.
CMCc: There's a codependance between developers and packagers, between packagers and users, and between users and developers. It would be in everyone's best interests to strive to find common ground, so that developers can make it easy to package, and packagers can make it easy to develop. It's my considered opinion, although it seems controversial, that the notion of a release is an artefact of commercial software, and in many or most cases is not the only way to organise the process of packaging and distributing FOSS over an always-on high-speed global internet.
DKF: IMHO, releases only really make a big difference when there are many other people and pieces of software depending on the software being released. If there's something that is only being used by one or two people, there is no need to do releases (and plenty of reasons not to!) If there are many thousands of people using the software in mission-critical situations, releases help a lot. I suppose this points to releases being a managerial structure that makes software development scale much better, and as such standard psychological techniques (especially in relation to effective group sizes) can be used to understand the point when it becomes worthwhile to start making releases.
CMCc: I agree with a lot of that, DKF: the best argument for having a release is to help control dependencies. It follows, then that this would only apply to library-like packages (packages with a clearly defined, published API).
It would also seem to suggest a versioned naming convention like major.minor where major releases don't introduce incompatible API changes. A similar effect could be achieved by naming the package 'product-API_number' and treating incompatible API changes as introducing a new 'product'. A release, then, could be a fairly infrequent event, if dependency control is what we're seeking to achieve.
escargo 28 Dec 2003 - Running cvs as a publically accessible service introduces a security issue on the server. (Of course, so does running FTP.)