Release mechanics

Diva releases in three forms:

• A major release, numbered 1.0 etc., A major release is the only release where we allow significant API changes. It's also the only type of release where we produce a complete set of documentation. Major releases are produced every six months to a year.

• A minor release. Minor releases are numbered x.1 etc. A minor release is a stable and functioning release, but may contain code in various stages of development. Minor releases, although stable, should be treated as alpha releases. Minor releases are produced every six to eight weeks.

• The snapshot release. The snapshot release is the current snapshot of the development tree. About the only thing we guarantee about the snapshot is that it builds and passes the automated smoke test. Snapshots are produced every few days.

We are taking a theme and feature-driven approach to driving releases. After each minor release, we decide on a "theme" for the next release. The theme is some overall guiding principle that we think is interesting, cool, and fits in with our research agendas. From the theme, we choose a set of features that we want to implement, using the theme to guide us in selecting which features to include, and which features to put on the list of "features to include some other time" list.

For example, suppose we decided that it was time to do an "informal user input" theme. We might choose features such as completing a gesture recognizer, adding a brush-stroked pen to the canvas, and implementing a gesture-driven version of the graph visualizer.

After making this list, we work like maniacs for a few weeks. Then we sit down and see how many of the features we might be able to actually include in the next release. We cross some of them off, produce a list of milestones that need to be done to make the release, and focus on getting those done.

Then we drink a lot of beer, and start again.