*  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:

   1 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.

   2 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

   3 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.

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

   5 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.

   6 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.

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

   8 Different user bases - packagers serve end users '''vs.''' developers serve fellow developers

   9 Discrete QA '''vs.''' continuous QA

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