Hi Tom,
As you noted, there is a lack of clarity about what it means to have a release. In my view, right now there are three categories of release product:
1. Services. From a user perspective, it is hard to tell when a service has been updated. I would suggest that there should be a client command that asks the server its version number/datestamp. This would be particularly useful in cases where a change to a service API might break some methods in the client—the client might want to interrogate the service about what version it is.
2. DMG/Ubuntu image. You mentioned that some people don’t think it’s worth the time and effort to put these together, but I wasn’t clear which side of the fence you fell on. I can definitely see both sides of this. I think these images are used by a small minority of power users, and that most people who use them either should be sticking with Iris, or, if they are developers, going the next step to using the Magellan images. It’s also clear that creating these images still requires significant human time—it would be nice if one could just type “make dmg” and it would all magically happen, but I gather there’s a fair amount of tinkering that’s necessary to make that work, and it might not be worth the effort. On the other hand, the dmg and ubuntu image are possibly the most visible release products, and that does count for something.
3. Iris. Until the Narrative is publicly available, it seems to me that Iris is the most visible measure of progress. Jim has made Iris show a version number and datestamp, so that users can tell when it was updated and what’s new:
<Screen Shot 2013-12-03 at 10.34.25 AM.png>
This makes it clear that Iris indeed has not been redeployed—not even in October.
Do you want me to ask Dan (and Jim) about that, so we can figure out what’s holding that up?
4. There’s a fourth thing that might be viewed as a release “product”, which is the data. It would be great if we could put something on our website after each data build that says the date of the data build and what’s new (N new data types [list], X new genomes, etc.).
In summary, I would propose that a (software) release consists of:
- Release team does an integrity check on services to be (re)deployed—passes tests, has appropriate documentation (including release notes)
- Redeployment of updated services and deployment of new services
- Iris updated on public site
- Internal announcement from the release team that the release has happened, including a list of which services are new and which are changed in this release (and presumably the info about what’s changed is included in the service release notes)
- Public announcement (which I am happy to put together, given the info about what’s new/changed) to be posted to
kbase.us
I think the dmg/ubuntu images are optional in this process.
Does this seem reasonable?
Nomi