Work in Progress

This document is currently under discussion

Update of November 2022: 

  • While we strive for a regular release, we recognize that our pattern has been to make a release when and if we have the capacity to do so.  
  • Looking back, we seem to have averaged one release per year, with an uptick in 2022 covering three releases.  
  • We should edit the following text that was created during the project's incubation period and the related confluence pages to be more accurate.  


Policy as adopted by the Project Management Committee (PMC) :

Release branches are created every two months at the beginning of the following month from the changes that were merged by the last day of the previous month.

If a feature is almost but not quite done at the end of the month, the release is not delayed for the feature.  That feature goes into the next release scheduled for two months later.

The name of the release is it's version.  As described in more detail in Versioning, the version number depends on whether the changes are backwards compatible or incompatible.

There is no code freeze for creating a release branch because we as committers only integrate things that pass the Code Review Guidelines.

Once a release branch is created and a release candidate is packaged, release stabilization proceeds as described in Stabilizing a release starting with a two week soak.







  • No labels

1 Comment

  1. Myrle Krantz

    Questions that still require answers:

    • How does feature testing before integration proceed?  Do we test on snapshots, or milestones? How is the milestone number determined?
    • Backwards compatibility needs to be more precisely defined.  Interfaces are (mostly) straightforward, but at what level is behavior backwards compatible? And what tools do we have for detecting backwards incompatibility?