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

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.