* 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.
- Dependency - external software must be able to easily express its dependency on a particular version's interface. A release's name may encode information about interface changes (major/minor release numbering) or the wisdom of depending on a given version (alpha/beta versioning.)
- Public statement of commitment 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 commitment) - 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 success - 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
- Discipline - a programmer who can't cleave to my distro's reasonable packaging prerequisites can't be producing anything worthwhile vs. Management is the informational analogue of friction: effort applied at a right angle to the direction of travel.
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.