Overview

Over the last couple of months we have been considering changing our Mbed OS release process. There are a number of reasons for this:

• We need to be able to release new functionality more frequently
• We need more flexibility to release features as they become mature (not released too early or delayed months before releasing) 
• We would like to simplify our branching strategy  
• It would allow us to improve the quality of our feature releases as they are not rushed to meet the current release cadence
• We need to be able to better support our Pelion Client release model

Our current release process

Currently we make an Mbed OS patch release every 2 weeks and a feature release quarterly. Our releases come from dedicated release branches (e.g. mbed-os-5.14). We then add a tag to the current release branch whenever we release from it. The releases are very regular and predictable and fixes to critical issues are available in regular patch releases  with only a 2 week response time.

However, we don’t accept new functionality in patch releases or breaking changes in patch/feature releases. This feature cadence thus:

• Drives behaviour to squeeze low quality content to release. 
• Means a delay of 3-4 months if the current feature release is missed.
• Causes bottlenecks in some teams, e.g. docs & maintainers, as the work tends to accumulate towards the end of the release cycle.
• Increases the complexity of integration and release due to the long time between releases .

New release process

From Mbed OS 5.14 onwards we are adopting a new release process.

From this point until Jan 2020 we will make a patch release once a month (on the 3rd Wednesday).

Then from Jan 2020 onwards we will continue to make a release once a month, on the 3rd Wednesday, however the type of release will depend upon the content of contributions to Mbed OS since the previous release:

• If we have only patches then we will make a patch release.
• If we have any new features, functionality or API changes then we will make a feature release.
• If we have any breaking changes then we will make a major release. However this should only happen infrequently.

It will be clear in our release documentation what type of release we are making and any specific impact this may have.

Changes to our branching strategy

As part of this process our branching strategy is also changing. From now on we are advising that all feature development should be done on stand alone feature branches. New features will only be accepted back to Master once they:

• are code complete
• have full, accompanying documentation
• include any associated tests and test results
• are fully reviewed and validated

Releases will then be made from Master when the next release is due.

Diagrammatic representation

Please feel free to raise a comment on our forums if you would like any further information.