Merge #7663

7663: Reformulation of changes after bundler 2.1 has been released r=deivid-rodriguez a=jesperronn

### What was the end-user or developer problem that led to this PR?

Upgrading document talks about bundler 2.1 in future tense, but it has already been released.

### What is your fix for the problem, implemented in this PR?

Update text to reflect the deprecation texts are already added in version 2.1, and that version 2.1 has already been released

Co-authored-by: Jesper Rønn-Jensen <jesperrr@gmail.com>

1 files changed, 2 insertions, 3 deletions

diff --git a/UPGRADING.md b/UPGRADING.md
index e26ad3bdb9..611a73a6d4 100644
--- a/UPGRADING.md
+++ b/UPGRADING.md
@@ -4,8 +4,7 @@
 
 The following is a summary of the changes that we plan to introduce in Bundler
 3, why we will be making those changes, and what the deprecation process will
-look like. All these deprecations will be printed by default in the upcoming
-Bundler 2.1 release.
+look like. All these deprecations are printed by default in the Bundler 2.1 release.
 
 If you don't want to deal with deprecations right now and want to toggle them
 off, you can do it through configuration. Set the `BUNDLE_SILENCE_DEPRECATIONS`
@@ -30,7 +29,7 @@ them.
 
 The CLI defines a set of commands and options that can be used by our users to
 create command lines that bundler can understand. There's a number of changes
-that we plan to make to this set of commands and options.
+in the upcoming 3 version.
 
 * Flags passed to `bundle install` that relied on being remembered across invocations have been deprecated.