dapr
/
community
mirror of https://github.com/dapr/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #503 from artursouza/update_release_info 

Versioning, tagging and branching
This commit is contained in:
Mark Fussell 2024-06-17 14:37:34 -07:00 committed by GitHub
parent 27760c27f7 a13b1d140a
commit 5251655204
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 16 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
release-process.md
View File

@ -4,7 +4,21 @@ The Dapr project aims to release four updates in a yearly time period, typically
<img src="images/release-cycle-diagram.png?raw=true">
This cadence provides a balance between regular feature releases and bug fixes, giving end users time to adopt a release and providing contributors clarity on releases they can contribute towards. By having a regular “train” of releases end users and contributors can plan ahead.
This cadence provides a balance between regular feature releases and bug fixes, giving end users time to adopt a release and providing contributors clarity on releases they can contribute towards. By having a regular “train” of releases end users and contributors can plan ahead.
Although this is the desired candence, imbalance between scope and availability of contributors and maintainers might impact the number of releases in a given year. Maintainers might decide to reduce the number of releases in order to have more time to finish high priority improvements.
## Versioning, tagging and branching
All release artifacts must follow [Semantic Versioning](https://semver.org). Each release milestone increments the minor version. In exceptional cases, the major version can be increased too.
See our documentation on [versioning policy](https://docs.dapr.io/operations/support/support-versioning).
At code freeze of a release milestone, the master (or main) branch is forked into a branch named `release-<MAJOR>.<MINOR>`, which lives forever. To trigger a release candidate or a release, tagging should happen in the correspondig release branch. For example, to release version `1.2.3`, the tag `v1.2.3` must be cut out of the `release-1.2` branch.
Hotfixes should also be applied directly into each of the impacted release branches. Then, the fix can be merged back into master (or main) branch or cherry-picked.
Ideally, a release should be 100% automated and require only the tag to be pushed upstream.
## Release milestone
The Dapr project is under continuous development addressing issues for both bugs on existing features and new features. Features go through a lifecycle from proposal, design, code, test, docs, and often quickstart and SDKs deliverables. Feature proposals can be raised and reviewed by the community and maintainers at any time.
@ -38,7 +52,7 @@ On assignment, the release team lead and shadow(s) are included into the Github
- [ ] Communicating status to the community on an on-going basis.
Read about the K8s release team selection [here](https://github.com/kubernetes/sig-release/blob/master/release-team/release-team-selection.md#selection-criteria).
As a reference, find the K8s release team selection [here](https://github.com/kubernetes/sig-release/blob/master/release-team/release-team-selection.md#selection-criteria)
## Feature definition phase (~2 weeks)
With ongoing feature definition, some set of issues will bubble up as targeting a given release. In this phase, a set of feature proposals and significant design changes to existing features are reviewed where contributors are able to dedicate time to completing the issue or starting an issue for a future release.