rubygems-update 3.4.10 → 3.5.22

data/POLICIES.md

@@ -65,6 +65,59 @@ Bundler:
     have to work on weekends.
 *   Continue with the regular release process below.
 
+### Branching
+
+Bundler releases are synchronized with rubygems releases at the moment. That
+means that releases for both share the same stable branch, and they should
+generally happen together.
+
+The current conventional naming for stable branches is `x+1.y`, where `x.y` is
+the version of `bundler` that will be released. This is because `rubygems-x+1.y`
+will be released at the same time.
+
+For example, `rubygems-3.2.0` and `bundler-2.2.0` were both released from the
+`3.2` stable branch.
+
+Once a stable branch has been cut from `master`, changes for that minor release
+series are only made _intentionally_, via patch releases. That is to say,
+changes to `master` by default _won't_ make their way into the current stable
+branch, and development on `master` will be targeting the next minor
+or major release.
+
+There is a `rake prepare_release[<target_rubygems_version>]` rake task
+that helps with creating a release. It takes a single argument, the _exact
+rubygems release_ being made (e.g.  `3.2.3` when releasing bundler `2.2.3`).
+This task checks out the appropriate stable branch (`3.2`, for example), grabs
+all merged but unreleased PRs from both bundler & rubygems from GitHub that are
+compatible with the target release level, and then cherry-picks those changes
+(and only those changes) to a new branch based off the stable branch. Then bumps
+the version in all version files, synchronizes both changelogs to include all
+backported changes and commits that change on top of the cherry-picks.
+
+Note that this task requires all user facing pull requests to be tagged with
+specific labels. See [Merging a PR](/bundler/doc/playbooks/MERGING_A_PR.md) for details.
+
+Also note that when this task cherry-picks, it cherry-picks the merge commits
+using the following command:
+
+```bash
+$ git cherry-pick -m 1 MERGE_COMMIT_SHAS
+```
+
+For example, for PR [#5029](https://github.com/rubygems/bundler/pull/5029), we
+cherry picked commit [dd6aef9](https://github.com/rubygems/bundler/commit/dd6aef97a5f2e7173f406267256a8c319d6134ab),
+not [4fe9291](https://github.com/rubygems/bundler/commit/4fe92919f51e3463f0aad6fa833ab68044311f03)
+using:
+
+```bash
+$ git cherry-pick -m 1 dd6aef9
+```
+
+After running the task, you'll have a release branch ready to be merged into the
+stable branch. You'll want to open a PR from this branch into the stable branch
+and provided CI is green, you can go ahead, merge the PR and run release tasks
+as specified below from the updated stable branch.
+
 ### Automatic changelog and backport generation
 
 PR labels and titles are used to automatically generate changelogs for patch and
@@ -79,40 +132,56 @@ changelog.
 If PRs don't have a proper label, they won't be backported to patch releases.
 
 If you want a PR to be backported to a patch level release, but don't want to
-include it in the changelog, you can use the special `rubygems: backport` and
-`bundler: backport` labels. For example, this is useful when backporting a PR
-generates conflicts that are solved by backporting another PR with no user
-visible changes. You can use these special labels to also backport the other PR
-and not get any conflicts.
+include it in the changelog, you can use the special `rubygems: skip changelog`
+and `bundler: skip changelog` labels. For example, this is useful when
+backporting a PR generates conflicts that are solved by backporting another PR
+with no user visible changes. You can use these special labels to also backport
+the other PR and not get any conflicts.
+
+### Breaking changes
+
+Bundler cares a lot about preserving compatibility. As a result, changes that
+break backwards compatibility should (whenever this is possible) include a feature
+release that is backwards compatible, and issue warnings for all options and
+behaviors that will change.
+
+We only release major breaking changes when incrementing the _major_ version of
+Bundler and RubyGems. However, experience shows that almost every single part of
+Bundler and RubyGems is depended on by someone in ways hard to anticipate. So if
+we were strict about breaking changes we'd need to hold on from making progress
+a lot, or continuously increment the major version, emptying "really major"
+versions from their meaning. Because of this, we also may release "small"
+breaking changes in minor releases. "Small" here means that we expect them to
+affect only very few users in rare cases.
 
 ### Steps for patch releases
 
 *   Confirm all PRs that you want backported are properly tagged with `rubygems:
     <type>` or `bundler: <type>` labels at GitHub.
-*   Run `rake prepare_release[<target_version>]`. This will create a PR to the
-    stable branch with the backports included in the release, and proper
+*   Run `rake prepare_release[<target_rubygems_version>]`. This will create a PR
+    to the stable branch with the backports included in the release, and proper
     changelogs and version bumps. It will also create a PR to merge release
     changelogs into master.
 *   Once CI passes, merge the release PR, switch to the stable branch and pull
     the PR just merged.
-*   Release `bundler` with `(cd bundler && bin/rake release)`.
+*   Release `bundler` with `rake bundler:release`.
 *   Release `rubygems` with `rake release`.
 
 ### Steps for minor and major releases
 
 *   Confirm all PRs that you want listed in changelogs are properly tagged with
     `rubygems: <type>` or `bundler: <type>` labels at GitHub.
-*   Run `rake prepare_release[<target_version>]`. This will create a new stable
-    branch off the master branch, and create a PR to it with the proper version
-    bumps and changelogs. It will also create a PR to merge release changelogs
-    into master.
+*   Run `rake prepare_release[<target_rubygems_version>]`. This will create a
+    new stable branch off the master branch, and create a PR to it with the
+    proper version bumps and changelogs. It will also create a PR to merge
+    release changelogs into master.
 *   Replace the stable branch in the workflows with the new stable branch, and
     push that change to the release PR.
 *   Replace version numbers with the next ".dev" version, and push that change
     to the master PR.
 *   Once CI passes, merge the release PR, switch to  the stable branch and pull
     the PR just merged.
-*   Release `bundler` with `(cd bundler && bin/rake release)`.
+*   Release `bundler` with `rake bundler:release`.
 *   Release `rubygems` with `rake release`.
 
 ## Committer Access

data/README.md

@@ -27,9 +27,7 @@ For more information about how to use RubyGems, see our RubyGems basics guide at
 
 ## Requirements
 
-* RubyGems 2.6 supports Ruby 2.4 or lower.
-* RubyGems 2.7 supports Ruby 2.5 or lower.
-* RubyGems 3.0 supports Ruby 2.3 or later.
+* RubyGems supports Ruby 3.0 or later.
 
 ## Installation