Project Release

• 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 nonexistent 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 function vs. a developer prefers function 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.

DKF: IMHO, releases only really make a big difference when there are many other people and pieces of software depending on the software being released. If there's something that is only being used by one or two people, there is no need to do releases (and plenty of reasons not to!) If there are many thousands of people using the software in mission-critical situations, releases help a lot. I suppose this points to releases being a managerial structure that makes software development scale much better, and as such standard psychological techniques (especially in relation to effective group sizes) can be used to understand the point when it becomes worthwhile to start making releases.

CMCc: I agree with a lot of that, DKF: the best argument for having a release is to help control dependencies. It follows, then that this would only apply to library-like packages (packages with a clearly defined, published API).

It would also seem to suggest a versioned naming convention like major.minor where major releases don't introduce incompatible API changes. A similar effect could be achieved by naming the package 'product-API_number' and treating incompatible API changes as introducing a new 'product'. A release, then, could be a fairly infrequent event, if dependency control is what we're seeking to achieve.

escargo 28 Dec 2003 - Running cvs as a publically accessible service introduces a security issue on the server. (Of course, so does running FTP.)

RKzn 2016-01-09 - one approach to major.minor versioning as CMCc suggested is Semantic versioning