From 7fd3a1bde6e79db8dd85d172febfe5b2942e6d95 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Arko?= Date: Sun, 19 Jan 2020 23:54:51 -0800 Subject: Revise compatibility policies This updates the written policies to reflect discussions, agreements, and public statements during 2019. --- doc/POLICIES.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/doc/POLICIES.md b/doc/POLICIES.md index 81a8a72f82..4c810c284f 100644 --- a/doc/POLICIES.md +++ b/doc/POLICIES.md @@ -17,9 +17,19 @@ Bundler tries for perfect backwards compatibility. That means that if something Bundler will provide features and bugfixes to older versions on a schedule similar to Ruby itself. For example, when Bundler 4.x is the current version, Bundler 4 will be eligible for new features and bugfixes. Bundler 3 will be eligible for bugfixes only. Bundler 2 will be eligible for security bugfixes only. Bundler 1 will be unsupported. -Bundler 2 and above will support Ruby and RubyGems versions for the same amount of time as the Ruby core team supports them. As of February 2018, that means no support for Bundler running on Ruby 2.2, security fixes only for Bundler running on Ruby 2.3, and full support (including new features and bugfixes) for Bundler running on Ruby 2.4 and 2.5. Unsupported Ruby versions will be dropped in the first Bundler minor release after support ends. +Bundler supports Ruby and RubyGems versions until the next major release after the Ruby core team drops support. For example, the Ruby core team will drop all Ruby 2.4 support on March 31, 2020. The next Bundler major release after that date will drop support for Ruby 2.4. -These policies are not a guarantee that any particular fix will be backported. Instead, this is a way for us to set an upper limit on the versions of Ruby, RubyGems, and Bundler that we have to consider while making changes. Without the limit, the number of versions grows exponentially over time and quickly becomes overwhelming, which leads to maintainer burnout. We want to avoid that. +### Release guidelines + +Bugfix releases should generally be cut as soon as possible. A bugfix release for a single PR is totally okay. + +Minor/feature releases can be cut anytime at least one new feature is ready, but don't have to be. Minor version releases should include an update to the documentation website. + +Major version releases should be cut no more than once per year, and must include a new section of the website with documentation for that major version. + +Major releases ideally happen after a Ruby version loses support in February or March, which helps us stay in sync with Ruby versions uspported by the core team. + +Breaking changes other than dropping support for old Ruby versions should be avoided whenever possible, but may be included in major releases. In general, breaking changes should include at least one major version (and one year elapsed) with a deprecation warning before the breaking change takes effect. ### User experience guidelines @@ -58,14 +68,6 @@ Always create pull requests rather than pushing directly to the primary branch. Contributors who have contributed regularly for more than six months (or implemented a completely new feature for a minor release) are eligible to join the maintainer team. Unless vetoed by an existing maintainer, these contributors will be asked to join the maintainer team. If they accept, new maintainers will be given permissions to view maintainer playbooks, accept pull requests, and release new versions. -### Release guidelines - -Bugfix releases should generally be cut as soon as possible. Multiple bugfix releases are preferable to waiting for a specific fix to land. - -Minor/feature releases can be cut anytime at least one new feature is ready, but don't have to be. Minor version releases should include an update to the documentation website, allowing users to view the documentation for whatever minor version they happen to be using. - -Major version releases should be cut no more than once per year, ideally between Ruby's release on December 25 and February 15 of the next year. Releasing soon after Ruby helps us stay in sync with deprecated Ruby versions. Breaking changes other than dropping support for old Ruby versions should be avoided whenever possible, but may be included in major releases. In general, breaking changes should include at least one major version with a deprecation warning before the breaking change takes effect. - ### Enforcement guidelines First off, Bundler's policies and enforcement of those policies are subsidiary to [Bundler's code of conduct](https://github.com/rubygems/bundler/blob/master/CODE_OF_CONDUCT.md) in any case where they conflict. The first priority is treating human beings with respect and empathy, and figuring out project guidelines and sticking to them will always come after that. -- cgit v1.2.1 From 4c0e9f9488b02af6bc8fd965ce158b3f6ecf5b8b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Arko?= Date: Sun, 19 Jan 2020 23:58:10 -0800 Subject: Return backporting caveat I didn't actually mean to delete this paragraph, whoops --- doc/POLICIES.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/POLICIES.md b/doc/POLICIES.md index 4c810c284f..46f10c797e 100644 --- a/doc/POLICIES.md +++ b/doc/POLICIES.md @@ -19,6 +19,8 @@ Bundler will provide features and bugfixes to older versions on a schedule simil Bundler supports Ruby and RubyGems versions until the next major release after the Ruby core team drops support. For example, the Ruby core team will drop all Ruby 2.4 support on March 31, 2020. The next Bundler major release after that date will drop support for Ruby 2.4. +These policies are not a guarantee that any particular fix will be backported. Instead, this is a way for us to set an upper limit on the versions of Ruby, RubyGems, and Bundler that we have to consider while making changes. Without the limit, the number of versions grows exponentially over time and quickly becomes overwhelming, which leads to maintainer burnout. We want to avoid that. + ### Release guidelines Bugfix releases should generally be cut as soon as possible. A bugfix release for a single PR is totally okay. -- cgit v1.2.1 From 713b3c82daf177631bd52ad42cd0b7cfd642bb22 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Arko?= Date: Mon, 20 Jan 2020 01:13:19 -0800 Subject: =?UTF-8?q?=E2=9C=82=EF=B8=8F?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit removes trailing whitespace (I hope) --- doc/POLICIES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/POLICIES.md b/doc/POLICIES.md index 46f10c797e..e4a9243374 100644 --- a/doc/POLICIES.md +++ b/doc/POLICIES.md @@ -29,7 +29,7 @@ Minor/feature releases can be cut anytime at least one new feature is ready, but Major version releases should be cut no more than once per year, and must include a new section of the website with documentation for that major version. -Major releases ideally happen after a Ruby version loses support in February or March, which helps us stay in sync with Ruby versions uspported by the core team. +Major releases ideally happen after a Ruby version loses support in February or March, which helps us stay in sync with Ruby versions uspported by the core team. Breaking changes other than dropping support for old Ruby versions should be avoided whenever possible, but may be included in major releases. In general, breaking changes should include at least one major version (and one year elapsed) with a deprecation warning before the breaking change takes effect. -- cgit v1.2.1 From edd70ffc1ceb2c6d5ea5f171827ba767c4ca813e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Arko?= Date: Sat, 25 Jan 2020 14:35:59 -0800 Subject: Clarify doc updates for minors --- doc/POLICIES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/POLICIES.md b/doc/POLICIES.md index e4a9243374..39d8747210 100644 --- a/doc/POLICIES.md +++ b/doc/POLICIES.md @@ -25,7 +25,7 @@ These policies are not a guarantee that any particular fix will be backported. I Bugfix releases should generally be cut as soon as possible. A bugfix release for a single PR is totally okay. -Minor/feature releases can be cut anytime at least one new feature is ready, but don't have to be. Minor version releases should include an update to the documentation website. +Minor/feature releases can be cut anytime at least one new feature is ready, but don't have to be. Minor version releases must also include any needed updates to the documentation website, plus a "What's new" page summarizing what was added. Major version releases should be cut no more than once per year, and must include a new section of the website with documentation for that major version. -- cgit v1.2.1 From 69d572b2da18ab94116ca3f84759108337b5c374 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Arko?= Date: Sat, 25 Jan 2020 14:43:19 -0800 Subject: more release edits keep editing, add tldr, mention man pages --- doc/POLICIES.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/POLICIES.md b/doc/POLICIES.md index 39d8747210..c82739e4c0 100644 --- a/doc/POLICIES.md +++ b/doc/POLICIES.md @@ -23,13 +23,13 @@ These policies are not a guarantee that any particular fix will be backported. I ### Release guidelines -Bugfix releases should generally be cut as soon as possible. A bugfix release for a single PR is totally okay. +**tl;dr**: Majors about once per year, minors for any finished features with docs, patches for any committed bugfix. -Minor/feature releases can be cut anytime at least one new feature is ready, but don't have to be. Minor version releases must also include any needed updates to the documentation website, plus a "What's new" page summarizing what was added. +Patch (bugfix) releases should generally be cut as soon as possible. A patch release for a single bugfix PR is totally okay. -Major version releases should be cut no more than once per year, and must include a new section of the website with documentation for that major version. +Minor (feature) releases can be cut anytime at least one new feature is ready, but don't have to be. Minor version releases must update their major version's man pages and docs website as needed, and should each have their own "What's new?" section. -Major releases ideally happen after a Ruby version loses support in February or March, which helps us stay in sync with Ruby versions uspported by the core team. +Major (breaking) version releases should be cut no more than once per year, and must include a new section of the docs website dedicated to that major version. Ideally, major releases will happen after a Ruby version loses support in February or March, to help us stay in sync with Ruby versions supported by the core team. Breaking changes other than dropping support for old Ruby versions should be avoided whenever possible, but may be included in major releases. In general, breaking changes should include at least one major version (and one year elapsed) with a deprecation warning before the breaking change takes effect. -- cgit v1.2.1