Add release process and docs by OrlinVasilev · Pull Request #5676 · vmware-tanzu/velero

OrlinVasilev · 2022-12-09T15:24:52Z

Signed-off-by: OrlinVasilev ovasilev@vmware.com

Accepted the DCO. Commits without the DCO will delay acceptance.
Created a changelog file or added /kind changelog-not-required as a comment on this pull request.
Updated the corresponding documentation in site/content/docs/main.

Signed-off-by: OrlinVasilev <ovasilev@vmware.com>

codecov-commenter · 2022-12-09T15:34:59Z

Codecov Report

Merging #5676 (2e3e30c) into main (2ce46bd) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #5676   +/-   ##
=======================================
  Coverage   40.92%   40.92%           
=======================================
  Files         239      239           
  Lines       20629    20629           
=======================================
  Hits         8442     8442           
  Misses      11570    11570           
  Partials      617      617

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

RELEASES.md

Signed-off-by: OrlinVasilev <ovasilev@vmware.com>

weshayutin

Thanks Orlin!

OrlinVasilev · 2022-12-14T20:18:13Z

@weshayutin did you see the

New Features

All features(Issues and PRs) that are aimed to be completed into the upcoming release must be labeled as X.YY-cadidate, where X.YY is the upcoming version.
All features that were not completed it into the upcoming release needs to be revisited and re-labeled for the next release, if they are still considered valid for the project! The decision will be made by the major stakeholders(maintainers).

Although Velero is supported by many companies, the Velero community is the core of new features and effort to make the project better and feature rich and more reliable with ever other release.

Not sure if it's grammatically good enough ! :)

RELEASES.md

Signed-off-by: OrlinVasilev <ovasilev@vmware.com>

yanji09 · 2023-04-26T00:43:01Z

RELEASES.md

+Velero releases will be versioned using dotted triples, similar to [Semantic Version](http://semver.org/). For this specific document, we will refer to the respective components of this triple as `<major>.<minor>.<patch>`. The version number may have additional information, such as "-rc1,-rc2,-rc3" to mark release candidate builds for earlier access. Such releases will be considered as "pre-releases".
+
+### Major and Minor Releases
+Major and minor releases of Velero will be branched from `main` when the release reaches to `RC(release candidate)` state. The branch format should follow `release-<major>.<minor>.0`. For example, once the release `v1.0.0` reaches to RC, a branch will be created with the format `release-1.0.0`. When the release reaches to `GA(General Available)` state, The tag with format `v<major>.<minor>.<patch>` and should be made with command `git tag -s v<major>.<minor>.<patch>`. The release cadence is around 3 months, might be adjusted based on open source event, but will communicate it clearly.


It would be better to change the release cadence is around 4 months instead of 3 months if aiming for 3 release per year.

yanji09 · 2023-04-26T00:49:15Z

RELEASES.md

+### Pre-releases
+`Pre-releases:mainly the different RC builds` will be compiled from their corresponding branches. Please note they are done to assist in the stabilization process, no guarantees are provided.
+
+### Minor Release Support Matrix


There is an existing matrix tracking here. Better to combine them in a single place to maintain it easily.

yanji09 · 2023-04-26T01:07:20Z

RELEASES.md

+This document describes the versioning and release process of Velero. This document is a living document, contents will be updated according to each releases.
+
+## Releases
+Velero releases will be versioned using dotted triples, similar to [Semantic Version](http://semver.org/). For this specific document, we will refer to the respective components of this triple as `<major>.<minor>.<patch>`. The version number may have additional information, such as "-rc1,-rc2,-rc3" to mark release candidate builds for earlier access. Such releases will be considered as "pre-releases".


Currently Velero use "-rc.1, -rc.2, rc.3" as additional information in the version number.

yanji09 · 2023-04-26T01:09:04Z

RELEASES.md

+Velero releases will be versioned using dotted triples, similar to [Semantic Version](http://semver.org/). For this specific document, we will refer to the respective components of this triple as `<major>.<minor>.<patch>`. The version number may have additional information, such as "-rc1,-rc2,-rc3" to mark release candidate builds for earlier access. Such releases will be considered as "pre-releases".
+
+### Major and Minor Releases
+Major and minor releases of Velero will be branched from `main` when the release reaches to `RC(release candidate)` state. The branch format should follow `release-<major>.<minor>.0`. For example, once the release `v1.0.0` reaches to RC, a branch will be created with the format `release-1.0.0`. When the release reaches to `GA(General Available)` state, The tag with format `v<major>.<minor>.<patch>` and should be made with command `git tag -s v<major>.<minor>.<patch>`. The release cadence is around 3 months, might be adjusted based on open source event, but will communicate it clearly.


The current branch format is `release-1.0' since all the related patch release for that minor release will be in this branch.

mateusoliveira43 · 2023-06-16T17:55:49Z

RELEASES.md

+Major and minor releases of Velero will be branched from `main` when the release reaches to `RC(release candidate)` state. The branch format should follow `release-<major>.<minor>.0`. For example, once the release `v1.0.0` reaches to RC, a branch will be created with the format `release-1.0.0`. When the release reaches to `GA(General Available)` state, The tag with format `v<major>.<minor>.<patch>` and should be made with command `git tag -s v<major>.<minor>.<patch>`. The release cadence is around 3 months, might be adjusted based on open source event, but will communicate it clearly.
+
+### Patch releases
+Patch releases are based on the major/minor release branch, the release cadence for patch release of recent minor release is one month to solve critical community and security issues. The cadence for patch release of recent minus two minor releases are on-demand driven based on the severity of the issue to be fixed.


I would change "minus" here. What about (I did not change the meaning of the phrase, right?)

Patch releases are based on the major/minor release branch. The release cadence for patch releases follows these rules:

most recent minor release: one month to solve critical community and security issues.

last two previous minor releases: are on-demand driven, based on the severity of the issue to be fixed.

mateusoliveira43 · 2023-06-16T18:03:39Z

RELEASES.md

+| Velero v1.8.x   | :white_check_mark: |
+
+### Upgrade path and support policy
+The upgrade path for Velero is (1) 2.2.x patch releases are always compatible with its major and minor version. For example, previous released 2.2.x can be upgraded to most recent 2.2.3 release. (2) Velero only supports two previous minor releases to upgrade to current minor release. For example, 2.3.0 will only support 2.1.0 and 2.2.0 to upgrade from, 2.0.0 to 2.3.0 is not supported. One should upgrade to 2.2.0 first, then to 2.3.0.


I would jump lines here to be easier to read. ex.:

The upgrade rule for Velero is

Patch releases are always compatible with its major and minor version.
For example: previous released 2.2.0, 2.2.1 and 2.2.2 can be upgraded to most recent 2.2.3 release.

Only the two previous minor releases can be to upgraded to current minor release.
For example: 2.1.0 and 2.2.0 can be upgraded to 2.3.0, but 2.0.0 can not be upgraded to 2.3.0. One should upgrade to 2.2.0 first, then to 2.3.0.

mateusoliveira43 · 2023-06-16T18:06:52Z

RELEASES.md

+The activity for next release will be tracked in the [Velero Wiki roadmap](https://github.com/vmware-tanzu/velero/wiki). If your issue is not present in the corresponding release, please reach out to the maintainers to add the issue to the project board.
+
+### New Features
+- All features(Issues and PRs) that are aimed to be completed into the upcoming release must be labeled as `X.YY-cadidate`, where X.YY is the upcoming version.


I would stick with the same variables. In the beginning of the file major, minor and patch were used

mateusoliveira43 · 2023-06-16T18:19:28Z

RELEASES.md

I felt difficult to understand some sections. I would suggest to have examples like in the "Upgrade path and support policy" section, to help readers understand each section

We can work together in this PR @OrlinVasilev , I think would be good for me to start to understand the project

mateusoliveira43 · 2023-06-16T18:20:30Z

RELEASES.md

Instead of markdown file in the project root, would not be better to add this directly to the website?

Add release process and docs

2e3e30c

Signed-off-by: OrlinVasilev <ovasilev@vmware.com>

OrlinVasilev added kind/changelog-not-required PR does not require a user changelog. Often for docs, website, or build changes Community Community Issues and discussions labels Dec 9, 2022

github-actions bot requested a review from a-mccarthy December 9, 2022 15:25

github-actions bot assigned OrlinVasilev Dec 9, 2022

weshayutin reviewed Dec 13, 2022

View reviewed changes

RELEASES.md Outdated Show resolved Hide resolved

weshayutin reviewed Dec 13, 2022

View reviewed changes

RELEASES.md Outdated Show resolved Hide resolved

Add release process and docs

ee83af2

Signed-off-by: OrlinVasilev <ovasilev@vmware.com>

weshayutin previously approved these changes Dec 14, 2022

View reviewed changes

reasonerjt reviewed Dec 20, 2022

View reviewed changes

RELEASES.md Show resolved Hide resolved

reasonerjt reviewed Dec 20, 2022

View reviewed changes

RELEASES.md Show resolved Hide resolved

Add release process and docs

741b8a7

Signed-off-by: OrlinVasilev <ovasilev@vmware.com>

OrlinVasilev dismissed weshayutin’s stale review via 741b8a7 March 23, 2023 07:31

OrlinVasilev requested review from pradeepkchaturvedi, reasonerjt, sseago and weshayutin and removed request for a-mccarthy and weshayutin March 23, 2023 07:32

sseago approved these changes Mar 27, 2023

View reviewed changes

OrlinVasilev requested a review from weshayutin March 27, 2023 15:08

yanji09 reviewed Apr 26, 2023

View reviewed changes

mateusoliveira43 reviewed Jun 16, 2023

View reviewed changes

RELEASES.md

Copy link

Contributor

mateusoliveira43 Jun 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of markdown file in the project root, would not be better to add this directly to the website?

Conversation

OrlinVasilev commented Dec 9, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov-commenter commented Dec 9, 2022

Codecov Report

Uh oh!

Uh oh!

Uh oh!

weshayutin left a comment

Choose a reason for hiding this comment

Uh oh!

OrlinVasilev commented Dec 14, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

New Features

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

OrlinVasilev commented Dec 9, 2022 •

edited

Loading

OrlinVasilev commented Dec 14, 2022 •

edited

Loading