mirrors/velero
1
0
Fork 0
mirror of https://github.com/vmware-tanzu/velero.git synced 2025-12-23 06:15:21 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Update doc

Browse Source 
Update README to clarify the backward compatibility.
Trivial update to the support process to reflect how issues are labeled
as for now.

Signed-off-by: Daniel Jiang <jiangd@vmware.com>
This commit is contained in:
Daniel Jiang
2023-03-22 13:54:42 +08:00
parent 29b5894be6
commit 838af53d3a
2 changed files with 6 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
README.md
View File

@@ -43,10 +43,6 @@ The following is a list of the supported Kubernetes versions for each Velero ver
| 1.10 | 1.18-latest | 1.22.5, 1.23.8, 1.24.6 and 1.25.1 |
| 1.9 | 1.18-latest | 1.20.5, 1.21.2, 1.22.5, 1.23, and 1.24 |
| 1.8 | 1.18-latest | |
| 1.6.3-1.7.1 | 1.12-latest | |
| 1.60-1.6.2 | 1.12-1.21 | |
| 1.5 | 1.12-1.21 | |
| 1.4 | 1.10-1.21 | |
Velero supports IPv4, IPv6, and dual stack environments. Support for this was tested against Velero v1.8.
@@ -54,6 +50,8 @@ The Velero maintainers are continuously working to expand testing coverage, but
If you are interested in using a different version of Kubernetes with a given Velero version, we'd recommend that you perform testing before installing or upgrading your environment. For full information around capabilities within a release, also see the Velero [release notes](https://github.com/vmware-tanzu/velero/releases) or Kubernetes [release notes](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG). See the Velero [support page](https://velero.io/docs/latest/support-process/) for information about supported versions of Velero.
For each release, Velero maintainers run the test to ensure the upgrade path from n-2 minor release. For example, before the release of v1.10.x, the test will verify that the backup created by v1.9.x and v1.8.x can be restored using the build to be tagged as v1.10.x.
[1]: https://github.com/vmware-tanzu/velero/workflows/Main%20CI/badge.svg
[2]: https://github.com/vmware-tanzu/velero/actions?query=workflow%3A"Main+CI"
[4]: https://github.com/vmware-tanzu/velero/issues

15
site/content/docs/main/support-process.md
View File

@@ -20,31 +20,24 @@ We will update the public Slack channel's topic to indicate that you are the poi
## During the Week
### Where we will monitor
- `#velero` public Slack channel in Kubernetes org
- `#velero-users` and `#velero-dev` public Slack channels in Kubernetes org
- [all Velero-related repos][0] in GitHub (`velero`, `velero-plugin-for-[aws|gcp|microsoft-azure|csi]`, `helm-charts`)
- [Project Velero Google Group][1]
### GitHub issue flow
Generally speaking, new GitHub issues will fall into one of several categories. We use the following process for each:
1. **Feature request**
- Label the issue with `Enhancement/User` or `Enhancement/Dev`
- Leave the issue in the `New Issues` swimlane for triage by product mgmt
- Label the issue with `kind/requirement`
1. **Bug**
- Label the issue with `Bug`
- Leave the issue in the `New Issues` swimlane for triage by product mgmt
1. **User question/problem** that does not clearly fall into one of the previous categories
- When you start investigating/responding, label the issue with `Investigating`
- Add comments as you go, so both the user and future support people have as much context as possible
- Use the `Needs investigation` label to indicate additional work needed to truly understand the problem or the root cause.
- Use the `Needs Info` label to indicate an issue is waiting for information from the user. Remove/re-add the label as needed.
- For the issues that require reproduction, add label `Needs reproduction` or `status/not-reproducible` to indicate the status.
- If you resolve the issue with the user, close it out
- If the issue ends up being a feature request or a bug, update the title and follow the appropriate process for it
- If the reporter becomes unresponsive after multiple pings, close out the issue due to inactivity and comment that the user can always reach out again as needed
## End of Week
We ensure all GitHub issues worked on during the week on are labeled with `Investigating` and `Needs Info` (if appropriate), and have updated comments so the next person can pick them up.
[0]: https://github.com/vmware-tanzu?q=velero&type=&language=
[1]: https://groups.google.com/forum/#!forum/projectvelero