The purpose of the release process
The Release Process is dedicated to creating a plan and then following and monitoring that plan to deliver an increment to the product. It is extremely important, especially in a community where there are lots of developers from different companies, countries, to have a common understanding of what and how we would like to achieve. The release plan will help us to coordinate our efforts to achieve agreed goals and to deliver proper, coded, tested, and working as an expected increment of product. To achieve that, we need to act in accordance with agreed rules, time schedule, and milestones.
Prerequisites
All who would like to attend community effort and contribution must follow bellow prerequisites:
- Read the Getting Started as a Contributor page (including Registration and User Creation, environment installation)
- Check/assign to one of the existing projects or create a proposal for a new project
Release Process
The unit piece of functionality/work which can be included in the release is represented by the Epic ticket in Jira. The release process consists of several Milestones in the pipeline of epics with clearly defined acceptance criteria. One can treat these acceptance criteria as a checklist that has to be followed to say that particular epic achieved this Milestone. Overall flow is outlined as follows:
- Invitation of proposals for features, enhancement requests - approved till M0
- Blueprints/Design/Architectural approval cut-off date (4 months before release date)
- Code delivery cut-off date (2 months before release date) - till M4
- Branch cut-off date (1 month before release date)
- Stabilize the branch and build daily builds for 1 month
- Release the stable build as Community Release
- Build weekly/bi-weekly if any change committed to the branch
Milestones goal and acceptance criteria
Milestone | Goal of the Milestone | Description of the Milestone - acceptance criteria |
---|---|---|
M0 | Declaration of participation in the release, initial scope of the release |
|
M1 | Identification of dependencies between modules and new functionalities, |
|
M2 | Feature/Functionality technical design freeze |
|
M3 | API freeze (beta available) |
|
M4 | Code freeze - only bug fixing allowed |
|
RC0 | Release candidates freeze - branch stabilization |
|
Deployment | Release deployment | official deployment executed |
Release Cadence, Life Time & Support
The initial release cadence is planned for every 6 months.
The Community intends to actively support any release for up to 9 months, where any bug fixes will be committed and made available.