# Release process research

## Goal:
Define the following
- [ ] [Release planning process](#Release-Planning)
- [ ] [Automated Release process](#Automated-releases)

## Release Planning

### Summary:
SIG-leads & PM plans high level features, takes the proposed feature to community meeting for inputs from contributors. After a week/10 days, roll the agreed features into milestones/roadmap.

### Background Research:

| Release | kubevirt | argoCD |
| -------- | -------- | -------- |
| Cadence | 3 releases per year (Follows K8s release process) | Release every 3 months |
| Supported releases | current, current -1, current - 2 |current, current -1, current - 2 |
|Automated | yes| yes|
| Automation script | [link](https://github.com/kubevirt/kubevirt/blob/main/hack/release.sh) |GH Actions|
|Semantic versioning| yes | yes |
| Major version | 0 | 2 |
| More details | [link](https://github.com/kubevirt/kubevirt/blob/main/docs/release.md) | [link](https://github.com/argoproj/argo-cd/blob/master/docs/developer-guide/release-process-and-cadence.md)

#### KubeVirt:

##### Release planning

* not much on milestones
* Looks like v1 planning is happening in google doc and getting converted to GH issues - https://docs.google.com/document/d/1KpCOIgiIfTsHQ_AA6xfr3ndgVc8fIs-BSUrdXFdVuxs/edit#heading=h.dnct0as4yxs1
* Quote from the doc - ``` We need to publish our roadmap and make it available for wider community discussion. How do we want to do this?
Github project possibly. Allows referencing items from multiple repos.
dvossel’s thoughts - start with this google doc, decide on what we want to accomplish, present it to the wider community for feedback, then formalize the result into a md file in the docs/ directory.```

#### ArgoCD:

##### Release planning
* Uses milestones
* Critical issues & features : Maintainers commit to work on it
* Nice to have: open for contributors. Maintainers will reveiw it
* Maintainers drive testing
* 2 weeks code freeze
* Milestones: Looks like maintainers drive it. Depending upon the capacity of the maintainers + the issue triage signal.

## Automated releases:
Goal is to release early, release fast. Inorder to achieve this, we need an automated process that we can rely on to make pach/minor version releases. This section lists some of the tools to provide an idea of what is available already, what can be taken and reused, or help decide if we want to write own own.

### Minimal requirements
- [ ] Pre-release testing AKA Pass automated e2e tests
- [ ] generate rel notes/changelog
- [ ] generate artifacts
- [ ] sign artifacts
- [ ] tag the release appropriately
- [ ] generate an announcement mesage with links to all the artifacts & changelog ( Nice to have. Less prone to error when one of the maintainers or someone responsible wants to share it with the community)

### Tools:
* https://semantic-release.gitbook.io/semantic-release/
* Can be used to generate and release packages, integrated with CI
* git push or a PR merge triggers release
* Need to ensure commit messages have certain keywords. Not sure if it is feasible because typos duh!
* Our own bash script/ GH actions

### Meta questions
* Do we want a new release for each and every PR merge?
* How many fixes or PRs constitute a release?
* How often do we want to release? - weekly, on-demand, or a combination of both
* How do we manage or align with the concept of release planning if we decide to release often?
* [name=sraghunathan] - possibly decouple releases from milestones, may be? milestones can mean high level features that goes into the project in Q1. Can be planned in advance to an extent and doesnt have to be pinned to an exact release version.
* How do we keep track of supported Konveyor minor releases? Or do we only support current.
* If we decide to support only current, how do we support the community? it is understandable that not everyone wants to run a current release in prod. Most folks would like to trail behind by a release atleast.
* Incorporate Supply chain security practices?