Propose a deprecation process for velero

As discussed in the velero community call [1]
This is a proposed deprecation policy for the
velero project based on the goharbor project.

[1] https://hackmd.io/Jq6F5zqZR7S80CeDWUklkA

Update GOVERNANCE.md

definitive deprecation times, well done

Co-authored-by: Orlix <OrlinVasilev@users.noreply.github.com>
Signed-off-by: Wesley Hayutin <weshayutin@gmail.com>

Update GOVERNANCE.md

Co-authored-by: Ivan Sim <1330522+ihcsim@users.noreply.github.com>
Signed-off-by: Orlix <OrlinVasilev@users.noreply.github.com>

Update GOVERNANCE.md

Co-authored-by: Ivan Sim <1330522+ihcsim@users.noreply.github.com>
Signed-off-by: Orlix <OrlinVasilev@users.noreply.github.com>

add note regarding deprecation window

Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>

add changelog file

Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
This commit is contained in:
Wesley Hayutin
2022-11-01 14:22:00 -06:00
committed by Shubham Pampattiwar
parent 9743a7ce56
commit 8e8c340dd1
2 changed files with 24 additions and 0 deletions

View File

@@ -107,6 +107,29 @@ Lazy consensus does _not_ apply to the process of:
* Removal of maintainers from Velero
## Deprecation Policy
### Deprecation Process
Any contributor may introduce a request to deprecate a feature or an option of a feature by opening a feature request issue in the vmware-tanzu/velero GitHub project. The issue should describe why the feature is no longer needed or has become detrimental to Velero, as well as whether and how it has been superseded. The submitter should give as much detail as possible.
Once the issue is filed, a discussion period begins which ends at the beginning of the second community meeting after the opening of the issue, and is held at the community meeting and on the issue itself; the person who opens the issue or a maintainer should add that date and time in a comment in the issue as soon after the issue is opened as possible.
The feature will be deprecated by a supermajority vote of 50% plus one of the project maintainers at the time of the vote tallying, which is 72 hours after the end of the community meeting that is the end of the comment period. (Maintainers are permitted to vote in advance of the deadline, but should hold their votes until as close as possible to hear all possible discussion.) Votes will be tallied in comments on the issue.
Non-maintainers may add non-binding votes in comments to the issue as well; these are opinions to be taken into consideration by maintainers, but they do not count as votes.
If the vote passes, the deprecation window takes effect in the subsequent release, and the removal follows the schedule.
### Schedule
If depreciation proposal passes by supermajority votes, the feature is deprecated in the next minor release and the feature can be removed completely after two minor version or equivalent major version e.g., if feature gets deprecated in Nth minor version, then feature can be removed after N+2 minor version or its equivalent if the major version number changes.
### Deprecation Window
The deprecation window is the period from the release in which the deprecation takes effect through the release in which the feature is removed. During this period, only critical security vulnerabilities and catastrophic bugs should be fixed.
**Note:** If a deprecated feature must remain available for general use for two releases after deprecation, perhaps a backup that uses this deprecated feature must be fully-supported for restore for four releases.
## Updating Governance
All substantive changes in Governance require a supermajority agreement by all maintainers.

View File

@@ -0,0 +1 @@
Propose a deprecation process for velero