It's an Internet world now, we're all just living in it. The cumulation of many software projects used to be RTM: the point at which the team could "release to manufacturing", meaning that someone burned a CD and put it in a box with shrink-wrap. Today, much of the most exciting software is on-line only, and that trend is only going to continue. So, doing a good job with the on-line release of software is more important than ever.
In building Google Code's project hosting feature, we've occasionally needed to balance the needs of developers and the needs of end-users of the software being developed. We aim to make it as easy as possible for developers to participate in open source projects. But, we also keep in mind that developers develop software for users to use. Sometimes we've had to force developers to plan ahead a bit so that they do a better job for end-users. Specifically, when it comes to releasing open source software, we had a mini-bill-of-rights in mind for the benefit of end-users:
- If you download something, you can unambiguously tell someone else exactly what version you downloaded. For example, when filing an issue about it.
- If you downloaded a release, you can always download that exact same release again. For example, if you need to reinstall and you can't upgrade.
- You can tell someone to download a certain version that you downloaded, and they will be able to do it, even later. For example, in written installation instructions.
- You can refer to a release by URL in a build script or a web page client-side include, and the same version will still be at that URL later. For example, when offering a Java or Javascript library for other developers to reuse in their own applications, without forcing each of them to set up a new way to redistribute your library.
This all points to the need for archival downloads: downloads that, once released, stay released. We strongly discourage the projects that we host from deleting downloads, and the contents of a download cannot be swapped out for other contents. Instead, each download must have a unique name, usually including a release number. And, old versions can only be marked as "deprecated" to keep the list of current downloads clean and let end-users know that that download is no longer supported. We make exceptions for common errors, such as uploading the wrong file. When active open source projects release regularly, they naturally use up their download space quota, and we happily grant them larger quotas rather than ask them to delete any part of their project's history.
