This document is an attempt to record the policies and processes that are used to govern the Bundler project–it’s not fixed or permanent, and will likely evolve as events warrant.
These policies are intended to be examples of how to apply these goals, and we realize that we can’t possibly cover every edge case or loophole. In any case where policies turn out to conflict with these goals, the goals should win.
Anyone is welcome to open an issue, or comment on an issue. Issue comments without useful content (like “me too”) may be removed.
Opening an issue to ask for help may eventually get you help, but chances are help will arrive faster if you post on Stack Overflow
Issues will be handled as soon as possible, which may take some time. Including a script that can be used to reproduce your issue is a great way to help maintainers help you. If you can, writing a failing test for your issue is even more helpful.
Contributions to RubyGems are made via GitHub pull requests, which must be approved by a project committer other than the author. To approve a PR, a maintainer can use GitHubs PR review feature. After that, if the original author is happy to merge the PR, she can press the merge button.
Anyone is welcome to contribute. Contributed code will be released under the same license as the existing codebase.
Pull requests must have passing tests to be merged. Code changes must also include tests for the new behavior. Squashing commits is not required.
Every pull request should explain:
Both RubyGems and Bundler support Ruby versions for as long as the Ruby team supports them, as listed here. When a Ruby version reaches end-of-life, the following minor release of RubyGems/Bundler will drop backwards compatibility with that Ruby version.
We also support the latest stable versions of JRuby and TruffleRuby, and constantly evaluate changes in Ruby implementation usage to potentially support more implementations.
The team ships features and bugfixes for the latest minor version. We may exceptionally backport security fixes to older series shipped with Rubies that are officially supported.
Security releases will be made for RubyGems and Bundler versions that were included in a currently-supported Ruby release. For example, if a version was shipped with a Ruby release, it will receive security fixes until that Ruby version reaches end-of-life.
We generally release bugfixes from the main branch and may mix bug fixes and new features in the same release. We do not guarantee bugfix releases for previous minor or major versions.
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.
We strive for backwards compatibility. Infrastructure should be as unsurprising as possible, so if something worked in version 1.x, it should continue to work in 1.y and 1.z. Changes in major versions (e.g., 1.x to 2.x) may not maintain full backwards compatibility. We may not always get it right, and there may be extenuating circumstances that force us into choosing between different kinds of breakage, but compatibility is very important to us.
In general, this is what we consider as “public API”:
The gem and bundle CLIs. Flags and commands will never be removed without
deprecation, but we may change the specific output of certain commands without
notice, unless a --parseable or equivalent flag is given. Don’t rely on
empty error output when checking success, since progress
may be logged to stderr. Instead, check the exit status of the command.
The documented Gemfile DSL (both methods and their options).
The lockfile format. We may introduce slight changes in new lockfiles, but we’ll keep being able to read what we previously generated and we’ll keep it the same by default and instead provide explicit tools to upgrade existing lockfiles to new formats.
Any documented methods in the RubyGems and Bundler namespaces, like
Bundler.with_original_env and similar.
Actual APIs meant to be used by other libraries, like the plugin API.
Entrypoints different from the CLI, like bundler/setup or
bundler/inline.
We will never intentionally break any of the above in patch or minor releases.
Internal classes and their methods (public or private) are not considered public API, but we are aware that they are used in many places. So we try not to break internal functionality that may be used by others, including proactively using code search tools in public code. That said, we may not always be able to avoid breaking things, and we may even intentionally introduce this kind of “breakage” in a minor release if we deem it affects very few users or edge cases. So be aware when using internals and ideally get in touch with us before doing so, so that we can help find the right APIs.
Large changes often benefit from being written out more completely, read by others, and discussed. GitHub Discussions is the preferred place for that to happen.
Committers may lose their commit privileges if they are inactive for longer than 12 months. Committer permission may be restored upon request by having a pull request merged.
This is designed to improve project maintainability by requiring committers to maintain familiarity with current development activity and to improve security by preventing idle committers from having their commit permissions compromised or exposed.
Always create pull requests rather than pushing directly to the primary branch. Try to get code review and merge approval from someone other than yourself whenever possible.
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.
First off, Bundler’s policies and enforcement of those policies are subsidiary to Bundler’s code of conduct 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.
When it comes to carrying out our own policies, we’re all regular humans trying to do the best we can. There will probably be times when we don’t stick to our policies or goals. If you notice a discrepancy between real-life actions and these policies and goals, please bring it up! We want to make sure that our actions and our policies line up, and that our policies exemplify our goals.
Policies are not set in stone, and may be revised if policy violations are found to be in the spirit of the project goals. Likewise, actions that violate the spirit of the project goals will be considered policy violations, and enforcement action will be taken. We’re not interested in rules-lawyering, and we will take action when needed to ensure that everyone feels safe and included.
If you are comfortable reporting issues to the entire Bundler team, please send an email to team@bundler.io. If you are not comfortable reporting to the entire team, for any reason, please check the maintainers team list and use email, Twitter, or Slack to report to a single maintainer of your choice. Anyone violating a policy or goal is expected to cooperate with the team (and the reporter, if they request it) to resolve the issue in a way that follows the project goals.
Interested in adding someone to the team? Here’s the process.
contributors.rakebundler.gemspec && rubygems-update.gemspec$ gem owner -a EMAIL bundler
When team members choose to retire, here’s how to remove someone from the team.
$ gem owner -r EMAIL bundler
contributors.rakeThese policies were set in order to reduce the burden of maintenance and to keep committers current with existing development and policies. RubyGems work is primarily volunteer-driven which limits the ability to provide long-term support. By joining Ruby Central you can help extend support for older RubyGems versions.