Deprecate use of id for vulnerabilityFindingDismiss mutation
Compare changes
- Matt Wilson authored
@@ -5,7 +5,7 @@
Be sure to link this MR to the relevant issues.
If there is no relevant deprecation issue, hit pause and:
Removals must be announced as deprecations at least 2 milestones in advance of the planned removal date.
If the removal creates a breaking change, it can only be removed in a major "XX.0" release.
By the 10th: Assign this MR to these team members as reviewers, and for approval:
@PM
@EM
@TW
@ProductDesigners
@PMM
By 7:59 PM UTC 15th (11:59 AM PT): EM/PM assigns this MR to the TW reviewer for final review and merge: @EM/PM
By 7:59 AM UTC 18th (11:59 PM PT 17th): TW Reviewer updates Docs by merging this MR to master
: @TW
Please review the guidelines for removals.
breaking change
.When the content is ready for review, the Technical Writer and Engineering Manager must
review it. Optional reviewers can include Product Marketing, Product Design, and the Product Leaders
for this area. Use the
Reviewers for Merge Requests
feature for all reviews. Reviewers will approve
the MR and remove themselves from the reviewers list when their review is complete.
The TW should review according to the criteria listed below. Review a removal MR with the same process as regular docs MRs. Add suggestions as needed, @ message the PM to inform them the first review is complete, and remove yourself as a reviewer if it's not yet ready for merge.
Removal notices should not be merged before the code is removed from the product.
removal
and remove
if necessary.When the PM indicates it is ready for merge and all issues have been addressed, start the merge process.
The removals doc's .md
file
must be updated before this MR is merged:
gitlab-org/gitlab
project).bin/rake gitlab:docs:compile_removals
.
If you want to double check that it worked, you can run bin/rake gitlab:docs:check_removals
to verify that the doc is up to date.If you have trouble running the rake task, check the troubleshooting steps.