You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 48 Next »

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.

MilestoneMilestone NameActions to achieve milestone

Timeline

Week number

Kickoff - M0Start of release cycle.
M00

M1

Initiate Commonalities & ICM
  • 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.
M0 + 2 week2

M2

Finalize Commonalities & ICM
  • Create release-candidate for Commonalities & ICM
  • Prepare public-release for Commonalities & ICM.
  • Complete initial PR reviews.
  • TSC Approval.
M1 + 10 weeks12

M3

Initiate Sub-projects / APIs
  • 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

10

M4

Finalize Sub-projects / APIs
  • 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

20

M5

Meta Release
  • Determine the acceptance of the release-candidates for inclusion in the meta-release
  • Bundle & publish meta-release
  • TSC Approval
  • Publish meta-release
M4 + 2 weeks22

M6

Post- Release
  • Review release process and identify areas for improvement. 
  • Release Retro.
    • Inputs from Sub Projects
  • TSC Approval.
M5 + 2 weeks24

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.

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: Releasing API versions

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 provide input to the meta-release page.
  • Declare the kick-off of the meta release.
  • Prepare starting at M4 and 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

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

The milestone status values are defined as follows:

MilestoneBefore M dataAfter M date
M0scope definitionkick-off done
M1wip / alphaalpha available for M2
M2wip / release-candidaterelease-candidate available for M3
M3API wip / alphaAPI alpha available for M4
M4API wip / release-candidateAPI release-candidate available for M5
M5meta-release preparationmeta-release published
M6retrospective ongoingmeta-release concluded

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.

For sub-projects that contain multiple APIs in separate files,

  • A folder per API shall be created for its development.
  • The meta-release page shall list the individual APIs in the table with the API version considered in the meta-release.
  • The API version used in the API release asset naming for pre- and public releases include the API name. However, the API OAS definition file only has the semver API version. 

API version tag

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

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

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

Release roadmaps can be found here: Meta-release planning


  • No labels