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 Releases for information and schedule for specific releases.
Overview
CAMARA releases is scheduled to twice per year at approximately 6 month intervals (May and November). Releases are named after major world cities in alphabetical order. See the CAMARA Release Roadmap for a list of previous and future releases.
Releases are administered and tracked by a Community Release Managers. Release status is discussed at the << TBC >>
Release Milestones
Release milestones and their associated tasks, are used to track the status of the release. The milestones and management tasks used in the release process are described in the table below.
| Milestone | Description | Timeline |
|---|---|---|
| Kickoff - M0 | Start of release cycle. | M0 |
| Initiate Commonalities & ICM - M1 | Scope of Work Products clarified. | M0 + 1 week |
| - Identify commonalities work products. | ||
| - Gather requirements for commonalities. | ||
| - Create initial PRs for commonalities. | ||
| - Complete initial PR reviews. | ||
| - Agree on the scope of commonalities. | ||
| - Select release candidates for commonalities. | ||
| TSC Approval. | ||
| Finalize Commonalities & ICM - M2 | Release of Commonalities. | M1 + 6 weeks |
| TSC Approval. | ||
| Initiate Sub-Projects / APIs - M3 | Scope Request to Sub-Projects / APIs. | M1 + 6 weeks |
| - Determine requirements for sub-projects/APIs. | ||
| - Create PRs for sub-projects/APIs. | ||
| - Review and finalize PRs. | ||
| - Confirm scope of sub-projects/APIs. | ||
| - Identify release candidates for sub-projects/APIs. | ||
| Finalize Sub-projects / APIs - M4 | Release of Sub-Projects / APIs. | M3 + 8 weeks |
| Testing & Acceptance. | ||
| - Conduct testing. | ||
| - Evaluate acceptance criteria. | ||
| Code Freeze | ||
| Meta Release | Release Retro. | M4 + 2 weeks |
| - Review release process and identify areas for improvement. | ||
| TSC Approval. | ||
Bundle & publish release - Common Release Date ("packaging done for the community release"). |
....................................
- Work products needed:
- Commonalities
- API-design-guidelines.md
- Camara_Versioning_Guidelines.md
- Glossary.md
- Linting rules (representing the guidelines)
- Identity & Consent Management
- CAMARA-API-access-and-user-consent.md
- CAMARA-AuthN-AuthZ-Concept.md
- Note: documents will be incorporated into Commonalities release at some point of time, until then they be referenced by Commonalities
- Release Management
- Overview of released APIs and their version and status
- Release management process
- For each (API) sub projects:
- API Definition(s)
- Following the Commonalities guidelines
- Successful linting check (with latest rules provided by Commonalities
- Inline documentation, usable together with swagger editor and redoc
- Test definitions
- .feature files according to guideline from Commonality (comes with v0.2.0)
- Supplementary documentation if needed to use or implement the API definition(s)
- User documentation should be including the API Definition
- API Definition(s)
- Commonalities
Dependencies
- Release Management <= Commonalities, API Sub Projects:
Scope Definitions: Each release cycle involves defining the scope of work for commonalities, and sub-projects/APIs.
Planned Releases: Release management maintains a centralized repository of planned releases for commonalities and sub-projects/APIs, including their respective scope definitions and timelines.
Releases from Sub-Projects/APIs: Information about releases from sub-projects/APIs is collected and documented. This includes details such as release version, release date, features implemented, bug fixes, and any other relevant information.
- API Sub-Projects <= Commonalities:
Release Dependency: All sub-projects/APIs depend on the release of commonalities documents and artifacts for their own releases.
Follow Commonalities Release: sub-projects/APIs need to synchronize their release cycles with the release of commonalities.
Integration Testing: Before each sub-project/API candidate release, integration testing is conducted to verify compatibility with the latest commonalities release. Any discrepancies or issues are addressed before proceeding with the sub-project release.
Documentation and Artefacts: Sub-projects/APIs reference specific versions of commonalities documents and artefacts as part of their release process. This information is documented and tracked to maintain traceability and ensure compliance.
- Commonalities <= Identity & Consent Management:
Release Alignment: Commonalities releases are closely aligned with the release cycles of Identity & Consent Management (I&CM). A release of commonalities refers to documents and artifacts within a release of I&CM.
Versioning and Tagging: Commonalities documents and artifacts are versioned and tagged according to Camara_Versioning_Guidelines.md
Dependency Management: I&CM provides the foundational framework for commonalities, which in turn serves as the basis for sub-projects/APIs. Any changes or updates in I&CM are reflected in commonalities, ensuring consistency and coherence across the CAMARA project.
Guidelines towards Sub Projects regarding releases and versioning
- ACTION: a task force to address the collected issues around release and versioning in sub project should be run in context of the Release Management working group
- Collected issues: https://github.com/camaraproject/ReleaseManagement/issues/9
- Commonalities documents which are relevant: