* What is a Project Release?
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.