My release software requirements
For most software releases I do to day, there are many complex requirements to other pieces of software, often developed in parallel. For example, the Dateable product today consists of a set of Zope Products for Plone. Many of these products (but not all) in turn contains many python libraries as subfolders, which are put into sys.path during the product initialization. Development of Dateable is mostly working on these python libraries, so a release of Dateable means not only tagging the Zope 2 product and packaging it, but also tagging and packaging these python products, some of which should be released as tgz and made available as eggs separately as well as making the Product bundle tgz.
So release gets very complex, so therefore I need software that does the thinking for me. And I’m not the only one, the release procedure for Zope 3 eggs is so complicated even Stephan Richter thinks it’s too complicated. And that’s complicated.
So, I’ve started collecting requirements for this software, and see what is available and if there is something that can be used as a base to start from. Please tell me if I’m wrong, and add your own requirements in comments if you have them.
First, some nomenclature:
- Repository: Some folder somewhere in an svn that has a trunk/branches/tags structure.
- Main software: The software you want to release including all it’s modules. This could be things like Zope3, Grok, Plone, Dateable or just a simple python module like say, the iCalendar module.
- Software part: Software that is intimately connected to the main software, but resides in a separate repository
I’m all the way here assuming you use svn. Support for other types of versioning software would be nice, of course.
Here is the features I need:
Automatically create release tags for all supported repositories.
When I give the release command, a tag should be created in the svn for the software that I am using, but also for all software parts it relies on. Basically, it should check any svn:external to see if that repository is also releasable, and in that case release it.
Automatically update svn:externals in the release-tag.
In a release-tag, all svn:externals need to point either to release-tags or to specific revisions. That means that the software after creating the release-tag needs to update all the svn:externals so that they point either to newly created release-tags or revisions.
Caveat: If your software has an svn:external that points to a repository that can not be released, and that repository in turn has an svn:external that doesn’t point to a release-tag or a revision, your release-tag is for all intents and purposes unstable, since you can’t make sure it actually points to what you are using when you release it. Hence, the releaseing must stop if this is the case. A parameter to force it to release anyway is probably going to be needed here.
Automatically update version.txt
The version.txt of the trunk should be of the 1.2.3dev format. This should be changed in the release tag to be 1.2.3, and the trunk should be updated to 1.2.4dev.
Bundleman has a neat feature here. It reads the CHANGES file, and look if you have filled in something under “New features”, and in that case it will update the minor version number. But if you only filled in the CHANGES under “Bugfixes” it will only increase the revision number. But this is optional, and it also assumes a versioning strategy that might not be used everywhere. Instead just releasing the version number in version.txt (with dropping the dev) and increasing the revision number with one is OK as a default. That does mean that the developers need to have the discipline to increase the version from 1.2.4dev to 1.3.0dev if they add new features.
Optional support for version numbers in the form 2.3dev, getting increased to 2.4dev could be nice.
Complain if the docs aren’t updated
The release software should refuse to make a release unless there is a version.txt, a changes-file and a readme-file. The changes and readme could be located in the root or in docs. It needs to be flexible about capitalization and extensions. CHANGES, changes.doc and Changes.txt should all work. Also, it should refuse to make a release unless the changes file has been touched since the last release.
It needs to run on both Unix, Windows and MacOS X, obviously.
OK, that’s all I can think of right now. The software I know of that comes closest to this is Bundleman. But to be useable it needs to be extended to support other version/changes file formats than the ones Nuxeo uses, and the separation between a bundle and a product needs to be removed so that it instead does recursive releasing. And that’s rather big changes.