* What is a Project Release?
   * What are they for?
   * What are they good for?

[Stu] (pro) and [CMcC] (anti) have been hammering on this topic, and a few points can be summarised here:

To generalise, packagers like Project Releases (and developers don't like releases) because:

   * Ease of downloading - packagers don't see why they should learn CVS '''vs.''' I had to learn it to create the repository, now you can at least learn login and checkout.

   * Consistency of naming - useful for referencing a given version of a package for bug reporting and fixing '''vs.''' apparently names like YYMMDD don't suffice

'''[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 8.4.5.1.  If you got one last week, it also claimed
to be version 8.4.5.1, 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.

   * Public statement of committment to the quality of the project's state - packagers assume that a release has undergone QA '''vs.''' developers might consider QA a continuous process.

   * Visibility - the perception that something unreleased is non-existent '''vs.''' developers don't deal in such perceptions.

   * Reliance/Reliability - a packager is committed to producing packages upon which users can place reliance '''vs.''' a developer may be less interested in reliability or reliance.

   * Warranty ''(related to committment)'' - a packager is the first point of contact when a package doesn't work, but there's not a lot they can do about it '''vs.''' show me where the license warrants anything?  I do my best and it's pretty good IMHO.

   * Single metric of performance - a packager prefers stability over functionality '''vs.''' a developer prefers functionality over stability [[note: gross generalisation]]

   * Different user bases - packagers serve end users '''vs.''' developers serve fellow developers (of course, every developer is also someone's end user)

   * Discrete QA '''vs.''' continuous QA

It's been an interesting argument, and points to a fundamental tension between the goals of the two groups.