Page History

WIP

Introduction

A CAMARA meta-release is the way CAMARA brings its APIs to market.

A meta-release consists of a set of public versions of curated APIs that went though the CAMARA meta-release process.

The purpose of this document is to describe the cadence, processes, milestones, and associated tasks used in the CAMARA meta-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.

...

Timeline

...

Week number

...

M1

...

• Scope of Work Products clarified  and recorded in dedicated issue.
• Identify commonalities work products.
• Create alpha release for Commonalities & ICM
• Create initial PRs for commonalities.
• Agree on the scope of commonalities.
• TSC review.

...

M2

...

• Create release-candidate for Commonalities & ICM
• Prepare public-release for Commonalities & ICM.
• Complete initial PR reviews.
• TSC Approval.

...

M3

...

• Scope Request to Sub-Projects / APIs.
• Determine requirements for Sub-projects / APIs.
• Create PRs for Sub-projects / APIs.
• Review and finalize PRs.
• Confirm scope of Sub-projects / APIs 
• Define API test cases.
• Define acceptance criteria.
• Create alpha release for for Sub-projects / APIs.

...

M1 + 8 weeks

...

M4

...

• Conduct testing and log test result.
• Evaluate and log acceptance criteria.
• Code Freeze
• Create release-candidate for Sub-Projects / APIs.
• Prepare public-release for Sub-Projects / APIs.
• Request approval of Sub-projects / APIs to Release Management WG for meta-release

...

M3 + 10 weeks

...

M5

...

• Determine the acceptance of the release-candidates for inclusion in the meta-release
• Bundle & publish meta-release
• TSC Approval
• Publish meta-release

...

M6

...

• Review release process and identify areas for improvement. 
• Release Retro.
  • Inputs from Sub Projects
• TSC Approval.

...

define

• the milestones of the meta-release (this page), and the supporting Meta-release Process documentation
• the activities expected from the different teams to move from one milestone to the next
• the way to report progress on the meta-release itself, on the Commonalities and ICM releases and on API releases

For the schedule and content of actual planned meta-releases, see CAMARA meta-releases.

Meta-release milestones

Meta-release milestones and their associated actions are used to progress and track the status of the meta-release. 

• A meta-release has 6 milestones, M0 through M6 described below. 
• For the typical milestone dates of a meta-release, please see the Meta-release Process.

The following table lists the meta-release milestones, and includes a high level view of the activities expected from the various teams to reach these milestones. 

More details on these for each team are documented here: 

• • Commonalities, ICM: release tracking and milestone activities
  • API Sub Projects: release tracking and milestone activities
  • Release Management: meta-release tracking and milestone activities
  • TSC: milestone activities

Processes

All CAMARA teams play their part in the meta-release process. An overview of the activities per team is shown in the above table.

The details on the activities for each team can be found in the below process descriptions:

• The process to manage a meta-release is described here: Meta-release Process
• The process for the Commonalities and ICM teams is described here: Commonalities and ICM release process
• Details on releasing an API version and the related API versioning are described here: API Release Process. 

Release cadence

CAMARA meta-releases are scheduled twice per year at approximately 6 month intervals (March and September). 

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 Release Contacts (Maintainers) page.

Team release contacts need to subscribe to the release management mailing list.

Process

Details on API versioning and the link with the release management is described here: Planning and releasing API versions. Meta-release names will be named SpringYY or FallYY where YY is the (short) year number.

Meta-release (M0, M5, M6)

A meta-release has 6 milestones, M0 through M6 described above. For the milestone dates per meta-release, please see the Meta-Release Planning.

The Release Management team has the following activities for each meta-release:

• Create the meta-release page under CAMARA meta-releases
• Inform all team's release contacts through the release management mailing list that they need to create the API release tracker as described here: How to track an API release.
• Declare the kick-off of the meta release.
• Starting at M4, prepare and publish the meta-release at M5.
• Conduct a meta-release retrospective as input to the next meta release

At M0 preparation,

• the Commonalities and ICM 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.
• all API Sub-project teams shall create their release tracker page(s) for the API version(s) they plan to contribute to the meta-release

An ongoing meta-release status is discussed in the Release Management working group meetings.

Meta-release progress is visible on the meta-release page created for each meta-release. The data is obtained as follows:

• the Commonalities and ICM data is updated directly on the meta-release page by the respective teams.
• the API data is managed by the API Sub-project teams on their API release tracker page.

Release milestone status

The milestone status values are defined as follows:

...

Commonalities & ICM (M0, M1, M2)

The Commonalities and ICM teams shall respectively update the related meta-release page table as follows:

• Whenever a new pre-release is made available, the (Pre-)Release tag column shall be updated with the latest pre-release tag link for the API version.
• The actual milestone dates shall be put in the table when the milestone is achieved. 
• The link to the release package, when available, shall be added at each pre-release change, and at M2.
• Once TSC approval is given at M2, the target public-release version shall be created for M5 and the meta-release page updated with the final public-release.

APIs (M0, M3, M4)

API Sub-project teams shall update their API release tracker for the API as follows: 

• With the each pre-release API version the API pre-release version and tag fields shall be updated.
• The actual milestone dates shall be put in the table when the milestone is passed.
• The link to the release package, if available, shall be added at each pre-release change, and minimally at M3 and M4.
• When M5 is passed, the link to the public-release API package shall be added.

For API Sub-projects that contain multiple APIs,

• All APIs of the release shall have the same API version.
• If not, a separate API Sub-project shall be created for the API with a different version and it shall be release separately.

API version tag

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

• API pre-releases can be created through initial, alpha or release-candidate API version tags and API version release packages. These pre-releases become more stable with increasing API versions. 

• after a pre-release is created, intermediate PRs shall set the API version to just "wip" to indicate its instability until a next pre-release is created. 

API version release package

Release packages shall 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

...