MonetDB releases and development

We decided to dedicate this blog post to providing information about the MonetDB releases and development cycles to our followers/users. While a lot of this information is on our website, this short guide explains in brief all relevant points.

MonetDB has a few (between one and three) feature releases per calendar year, named after the year and month they were released in (e.g. “Jan2014”). Aside for introducing new capabilities, the feature releases are also used for deprecating features. Once the decisions for removing a feature from MonetDB is made, it will be present for at most two following features releases. Although great care is given to make upgrades transparent, there may arise cases where the underlying database structures have to be changed. Such cases are always reserved for feature releases and may, in the worst case, require a dump/restore.

The frequency of these releases is dependent on the availability and stability of new features, developed by the MonetDB/CWI team and partners. A new features is generally considered an extension of the capability of any layer of MonetDB (kernel, backend or frontend) or another database module/extension. Between the feature releases, smaller “bugfix” releases are made when needed. As the name suggests, these containing only fixes. They are tagged with SP (Service Pack) moniker (e.g. Jan2014-SP3).

The current development of MonetDB can be seen on our openly Mercurial tracker. There are three main branches: stable, candidate, and development, which are place holders for the actual branch names. The stable branch is named after the last MonetDB feature release and is only updated with fixes. The candidate branch often does not exist and it is only created in preparation of a new release. T he development branch is where the primary ongoing development towards a stable release is done. Currently the branches are:

  • stable: Jan2014
  • candidate: Oct2014
  • development: default

Fixes go to the first branch in the sequence stable, candidate, development in which the bug occurs. A new candidate branch is always created as a clone of the development (default) one. As such the default branch is a good starting point for new development.

In addition there are numerous feature branches, where the more experimental (and usually unstable) new features are being developed by the MonetDB team. Once that work is considered feature complete and stable it is merged with the default branch in preparation inclusion in an upcoming release.

We have an automated test system that continuously validates the code changes. The system builds the code and validates it against a large number of test sets. The test suite is also continuously extended with reported issues and subsequent fixes. The test environment covers a number of operating systems (Windows, several Linux distribution, OS X, Solaris) as well as hardware architectures (x86, x86_64, PowerPC, SPARC), to insure the portability of MonetDB.