---
# System prepended metadata

title: Release Planning
tags: [Contributor experience]

---

# Release Planning
This document captures the process the Konveyor project follows for planning work for Releases

# Summary
1. A Roadmap is maintained to communicate the future goals the project is seeking to deliver in long term
2. Goals for a release are decided on a regular basis to guide work to satisfy the longer term vision. 
3. SIG leads and one/two steering representatives will discuss the feature requests and plan for releases 
4. Each SIG conducts regular planning/triage calls to groom their respective backlogs and discuss work toward release goals
5. Prior to forming a release the maintainers assess what is 

## Roadmap
A forward looking vision of desired themes to implement in Konveyor as a unified experience will be maintained in our Roadmap.  This will be published as a Markdown document (https://hackmd.io/@konveyor/ryVJ7kBPi)



## Release Cadence

* Konveyor will follow a 4 month release cycle, in which it gets thoroughly tested through automation. Each release will have information regarding the versions of the components included.

* Each individual component/project will have their own release cadence, to facilitate faster iterations. 

## Release Versioning
We will adopt and conform to [semver](https://semver.org/) for our release versioning


## Sprint Plan
SIGs have a bi-weekly planning meeting and use GH projects to track the items. They go through the list of issues/bugs/Enhancements and track them in the upcoming milestones.

Existing boards: 
* SIG-addons 
    * For CI - https://github.com/orgs/konveyor/projects/47/views/1
    * For addons - https://github.com/orgs/konveyor/projects/48/views/1
* SIG-analyzer - https://github.com/orgs/konveyor/projects/46 
    * Small milestone boards - https://github.com/orgs/konveyor/projects/46/views/5 

## Sprint Review

Every two weeks, each SIG will present a demo at the community meeting and showcase the milestone accomplishments. 

## Usage of FeatureFlags
Larger features are encouraged to be implemented behind feature flags to allow a form of 'alpha' software to make it's way to users sooner, while providing a level of safety for those not ready to try experimental work.