CAMARA Release Process

WIP

Introduction

The purpose of this document is to describe the cadence, processes, milestones, and associated tasks used in the CAMARA release cycle. See CAMARA meta-releases for information and schedule for specific releases.

Release Milestones

Release milestones and their associated tasks, are used to track the status of the meta-release. The milestones and management tasks used in the release process are described in the table below.

Release cadence

CAMARA meta-releases are scheduled twice per year at approximately 6 month intervals (March and September). Meta-releases are named after major world cities in alphabetical order.

Process

Release contacts 

Meta-releases are administered and tracked by

• the CAMARA Release Managers, supported by
• the release contacts of the Commonalities and ICM working groups 
• the release contacts of the API Sub-projects

The teams can put their release contact names on the Sub-project Release Contacts (Maintainers) page.

Meta-release

• Create the meta-release page
• Inform the teams through the release management mailing list that they need to provide input to the meta-release page.
• Declare the kick-off of the meta release
• Publish the meta-release at M5
• Conduct a meta-release retrospective as input to the next meta release

At M0 preparation, the below teams shall update the meta-release page with the information of what they plan to contribute to the meta-release, and with the status updates during the meta-release cycle.

Release milestone status (M0, M5, M6)

Meta-release have 6 milestones, M0 through M6 described below. For the milestone dates per meta-release, please see the CAMARA Meta-release Roadmap.

The ongoing meta-release status is discussed in the Release Management working group meetings and recorded on the meta-release page.

The milestone status information is 

• M0: meta-release preparation, kick-off
• M1: scoped, work-in-progress
• M2: release-candidate, released
• M3: scoped, work-in-progress
• M4: release-candidate, released
• M5: meta-release finalization, published
• M6: under retro, done

Commonalities & ICM (M0, M1, M2)

The Commonalities and ICM teams shall respectively update the related table as follows:

• The Version column shall be updated with the latest pre-release version in use by the respective teams.
• The actual milestone dates shall be put in the table when the milestone is passed. 
• The link to the release package shall be added at each version change, and at M2 (and is the same at M5).
• When M2 is passed, the target public-release version shall be put in the Version column.

APIs (M0, M3, M4)

API Sub-project teams shall update the table for APIs as follows: 

• The Version column shall be updated with the latest pre-release API version in use by the team.
• The actual milestone dates shall be put in the table when the milestone is passed. 
• The link to the release package shall be added at each version change, and minimally at M3, M4, and the final at M5.
• When M5 is passed, the target public-release API version shall be put in the Version column.

Release branches

• the main branch always contains the latest API version. It is meant for development.   

• API versions can be frozen in a work-in-progress pre-release branch or in a release-candidate pre-release branch. These pre-releases become more stable with increasing pre-release numbers.

• Each pre-release branch has a pre-release tag. 
• Considering an API Family with more APIs inside, a Release Tag and a new Release Branch is done when all the APIs are completed.

Release packages

Release packages can be creates using the GitHub release process. 

Each release package shall include the release notes using the provided template.

Each release package has a tag: pre-release or latest.

Meta-release roadmap

Release roadmaps can be found here: CAMARA Meta-release Roadmap