| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously, sudo specs were running against system ruby, not against RVM
ruby. We need to make sure `sudo` is always configured to preserve the
path the `ruby`. This was previously done only for ruby 2.3, but needs
to be done everywhere to ensure that the specs run against the correct
ruby.
Together with this change, I added a bare test to make sure that "sudo
specs" run against the correct ruby.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7664: Bump man pages month r=deivid-rodriguez a=deivid-rodriguez
<!--
Thanks so much for the contribution!
If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.
To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->
### What was the end-user or developer problem that led to this PR?
CI fails when man pages month gets out of date.
### What is your fix for the problem, implemented in this PR?
My fix is to update the month in the man pages to the current one.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7580: Automultiplatform again r=indirect a=deivid-rodriguez
This PR is a reintroduction of #7215, now that I consider the multiplatform feature usable enough.
### What was the end-user problem that led to this PR?
The problem was that currently if the gemfile include gems for specific platforms, like the default `gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby]` Rails uses, bundler will always print a noisy warning, but I don't think users are doing anything wrong, just running `bundle install` on it.
Also, unless they run `bundle lock --add-platform x86-mingw32 x86-mswin32 x64-mingw32 java`, and commit the resulting lockfile, they will continue to get the same warning over and over again.
### What was your diagnosis of the problem?
My diagnosis is that the fact that some gems will be unused under some platforms is inherent to the multiplatform feature itself, so we shouldn't warn about it because it's expected.
Take the following Gemfile for example (a simplification of the default Gemfile Rails generators create):
```ruby
source "https://rubygems.org"
gem "rails"
gem "tzinfo-data", platforms: "jruby"
```
If I type that Gemfile, it means that I'm explicitly opting into the multiplatform feature. So the behavior I would want as a user when I run `bundle install` on it is:
* Resolve and lock the Gemfile for all platforms (`jruby` and whatever platform I'm running).
* Install the resolution for the platform that I'm currently running.
That way, when the other developers of my team using `jruby` install the `Gemfile`, they install a predictable, deterministic resolution.
Currently, the only way to get that behavior is to run:
```
$ bundle install
$ bundle lock --add-platform java
```
But there's no way to do it without getting a warning on the first `bundle install`, which annoys people because it makes you think you're doing something wrong.
If you only plan to use MRI, you shouldn't specify any jruby-specific gems in your Gemfile and write instead:
```ruby
source "https://rubygems.org"
gem "rails"
```
If on the other hand you only plan to use jruby, then you should not specify any `platform` option at all and write
```ruby
source "https://rubygems.org"
gem "rails"
gem "tzinfo-data"
```
So, to sum up, I think the range of platforms users expect to support can be guessed implicit from the Gemfile and the running platform. So we should resolve by default for all those platforms and don't warn about behavior that's most likely expected.
### What is your fix for the problem, implemented in this PR?
My fix is to do the right thing by default, and not warn users at all. That is:
* Resolve the gemfile and lock it for all platforms present in the Gemfile.
* Install gems for the current platform if requested.
### Why did you choose this fix out of the possible options?
I chose this fix because I think it's better for our users. We currently have a specific setting to avoid this warning, which I guess we added given the complaints. We no longer need that setting, nor the warning, so I removed both.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | |
| |
| |
| | |
This reverts commit 13cef81582858af9509726f3a24a817cf029ad9b.
|
| | |
| |
| |
| | |
This reverts commit b4cc36deb9749fba603d149e2b8e71b10cb331f1.
|
| | |
| |
| |
| | |
This reverts commit e93bce3b206895a46b9fb5889c5f908fd29ad554.
|
| | |
| |
| |
| | |
This reverts commit b5766564fb6ad9c74c3b87ad6b2965f3b9095d08.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
7590: Prepend debug label to resolver's debug message r=deivid-rodriguez a=kou
### What was the end-user problem that led to this PR?
The problem was not a end-user problem. This was a developer problem.
If we have many debug messages (for example, I added many `pp [...]` to debug #7522), it's difficult to find resolver's debug messages.
### What was your diagnosis of the problem?
My diagnosis was no common keywords in resolver's debug message is a problem. If we have a common keyword, we can find resolver's debug messages from many debug messages easily.
### What is your fix for the problem, implemented in this PR?
My fix prepends `BUNDLER: ` to all resolver's debug messages. If we have the same label in all resolver's debug messages, we can find resolver's debug message easily. For example, we can use "/BUNDLER:" in less.
### Why did you choose this fix out of the possible options?
I chose this fix because `BUNDLER: ` will not conflict. Other candidate is `DEBUG: ` but it may be used by other library. If the keyword conflicts, it's not easy to find resolver's debug messages. `Bundler::Resolver: ` will be more safer but it may be long.
Co-authored-by: Sutou Kouhei <kou@clear-code.com>
|
| | |
| |
| |
| |
| |
| | |
If we have the same label in all resolver's debug messages, we can find
resolver's debug message easily. For example, we can use "/BUNDLER:"
in less. It's useful when we have many debug messages.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7629: Adhere to gemfile name preference also for project skeleton. r=deivid-rodriguez a=dunrix
Fixes #7626.
Resolving gemfile name preference - original `Gemfile` or newer `gems.rb` moved to Bundler's singleton as being shared by multiple classes, ie. because of DRY principle.
Co-authored-by: Masha <no.public@email.sorry>
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7650: Bump rake version to 13.0 everywhere r=deivid-rodriguez a=deivid-rodriguez
<!--
Thanks so much for the contribution!
If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.
To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->
### What was the end-user or developer problem that led to this PR?
<!-- Write a clear and complete description of the problem -->
The problem is rake 12 prints a bunch of warnings on ruby 2.7.
### What is your fix for the problem, implemented in this PR?
<!-- Explain the fix being implemented. Include any diagnosis you run to
determine the cause of the issue and your conclusions. If you considered other
alternatives, explain why you end up choosing the current implementation -->
My fix is to upgrade rake everywhere.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7649: Fix resolving specs when run against a dev ruby snapshot r=deivid-rodriguez a=deivid-rodriguez
<!--
Thanks so much for the contribution!
If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.
To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->
### What was the end-user or developer problem that led to this PR?
The problem is that in some dev ruby builds, `RUBY_PATCHLEVEL` is `-1`, so the spec crashes because of an ill-formed requirement.
See for example https://github.com/rubygems/rubygems/pull/3077/checks?check_run_id=457988784.
<!-- Write a clear and complete description of the problem -->
### What is your fix for the problem, implemented in this PR?
<!-- Explain the fix being implemented. Include any diagnosis you run to
determine the cause of the issue and your conclusions. If you considered other
alternatives, explain why you end up choosing the current implementation -->
My fix is to change the spec to respect a `RUBY_PATCHLEVEL` equal to `-1`, by reusing code that handles that case.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ /
| |
| |
| |
| | |
In some dev builds, `RUBY_PATCHLEVEL` is `-1`, so the spec crashes
because of an ill-formed requirement.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7644: Unfreeze dependency hashes r=deivid-rodriguez a=deivid-rodriguez
<!--
Thanks so much for the contribution!
If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.
To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->
### What was the end-user or developer problem that led to this PR?
<!-- Write a clear and complete description of the problem -->
Running `bin/rake spec:deps` from jruby crashes with:
```
rake aborted!
FrozenError: can't modify frozen Hash
/path/to/bundler/spec/support/rubygems_ext.rb:36:in `dev_setup'
/path/to/bundler/Rakefile:29:in `block in <main>'
/path/to/bundler/Rakefile:14:in `block in invoke'
/path/to/bundler/Rakefile:13:in `invoke'
/path/to/bundler/spec/support/rubygems_ext.rb:98:in `gem_load_and_activate'
/path/to/bundler/spec/support/rubygems_ext.rb:45:in `gem_load'
Tasks: TOP => spec:deps
(See full trace by running task with --trace)
```
### What is your fix for the problem, implemented in this PR?
<!-- Explain the fix being implemented. Include any diagnosis you run to
determine the cause of the issue and your conclusions. If you considered other
alternatives, explain why you end up choosing the current implementation -->
Unfreeze the hashes, since we are modifying them.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These hashes are actually modified. For example, to exclude some
dependencies under jruby.
So they should not be frozen.
Without this, running `bin/rake spec:deps` from jruby crashes with:
```
rake aborted!
FrozenError: can't modify frozen Hash
/path/to/bundler/spec/support/rubygems_ext.rb:36:in `dev_setup'
/path/to/bundler/Rakefile:29:in `block in <main>'
/path/to/bundler/Rakefile:14:in `block in invoke'
/path/to/bundler/Rakefile:13:in `invoke'
/path/to/bundler/spec/support/rubygems_ext.rb:98:in `gem_load_and_activate'
/path/to/bundler/spec/support/rubygems_ext.rb:45:in `gem_load'
Tasks: TOP => spec:deps
(See full trace by running task with --trace)
```
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7646: Pin jruby-jars in warbler test r=deivid-rodriguez a=deivid-rodriguez
<!--
Thanks so much for the contribution!
If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.
To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->
### What was the end-user or developer problem that led to this PR?
<!-- Write a clear and complete description of the problem -->
The problem is that our CI is broken after the jruby-9.2.10.0 release.
### What is your fix for the problem, implemented in this PR?
My workaround is to pin the jruby-jars dependency of the warbler test to 9.2.9.0.
<!-- Explain the fix being implemented. Include any diagnosis you run to
determine the cause of the issue and your conclusions. If you considered other
alternatives, explain why you end up choosing the current implementation -->
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ /
| |
| |
| | |
It no longer works with jruby-jars 9.2.10.0.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7635: Update code of conduct template to CC2.0 r=colby-swandale a=CoralineAda
### What was the end-user or developer problem that led to this PR?
The Contributor Covenant was updated to version 2.0 last year, but bundler was still using the old version.
### What is your fix for the problem, implemented in this PR?
I updated the `.md.tt` file containing the template, careful to preserve the interpolation of the email address.
Co-authored-by: Coraline Ada Ehmke <coraline@idolhands.com>
|
| | | | |
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7633: Use `bundle config` instead of a deprecated flag in an error message. r=colby-swandale a=tatsuyafw
### What was the end-user or developer problem that led to this PR?
When trying to install gems to the system RubyGems and it fails, bundler shows a message as follows:
```
$ bundle install
# snip
Your user account isn't allowed to install to the system RubyGems.
You can cancel this installation and run:
bundle install --path vendor/bundle
to install the gems into ./vendor/bundle/, or you can enter your password
and install the bundled gems to RubyGems using sudo.
```
But the `--path` flag is deprecated, `bundle install --path vendor/bundle` shows:
```
$ bundle install --path vendor/bundle
[DEPRECATED] The `--path` flag is deprecated because it relies on being remembered across bundler invocations, which bundler will no longer do in future versions. Instead please use `bundle config set path 'vendor/bundle'`, and stop using this flag
# snip
```
### What is your fix for the problem, implemented in this PR?
This PR changes the message to show `bundle config set --local path` instead of the deprecated `--path` flag.
Co-authored-by: Tatsuya Hoshino <tatsuya7.hoshino7@gmail.com>
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When trying to install gems to the system RubyGems and it fails,
bundler shows the message as follows:
```
Your user account isn't allowed to install to the system RubyGems.
You can cancel this installation and run:
bundle install --path vendor/bundle
to install the gems into ./vendor/bundle/, or you can enter your password
and install the bundled gems to RubyGems using sudo.
```
But the `--path` flag is deprecated.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7622: Fix config location edge case r=deivid-rodriguez a=deivid-rodriguez
<!--
Thanks so much for the contribution!
If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.
To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->
### What was the end-user or developer problem that led to this PR?
<!-- Write a clear and complete description of the problem -->
The problem was that if `BUNDLE_APP_CONFIG` is set to an absolute path, and there's no Gemfile up in the directory hierarchy, bundler would end up using the default config location instead of the customized one.
### What is your fix for the problem, implemented in this PR?
My fix is to completely avoid bundler's root resolution for resolving the config path in this case, since `BUNDLE_APP_CONFIG` includes all the information we need to know.
<!-- Explain the fix being implemented. Include any diagnosis you run to
determine the cause of the issue and your conclusions. If you considered other
alternatives, explain why you end up choosing the current implementation -->
Fixes #7610.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If `BUNDLE_APP_CONFIG` is set to an absolute path, and there's no
Gemfile up in the directory hierarchy, bundler would end up using the
default config location instead of the customized one.
This commit fixes that.
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7630: More paralelization improvements r=deivid-rodriguez a=deivid-rodriguez
<!--
Thanks so much for the contribution!
If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.
To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->
### What was the end-user or developer problem that led to this PR?
The developer problem is that CI is still failing sometimes. The reason is most likely due to side effects when parallelizing specs, since specs still change the current folder globally sometimes.
### What is your fix for the problem, implemented in this PR?
My changes stop changing folders globally in more places, to try to alleviate these issues.
<!-- Explain the fix being implemented. Include any diagnosis you run to
determine the cause of the issue and your conclusions. If you considered other
alternatives, explain why you end up choosing the current implementation -->
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7614: Workaround jruby issue r=deivid-rodriguez a=deivid-rodriguez
<!--
Thanks so much for the contribution!
If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.
To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->
### What was the end-user or developer problem that led to this PR?
The problem is that if a Gemfile contains `:path` gem with a relative path, the bundler environment no longer works when the app is packaged as a `jar` with [warbler](https://github.com/jruby/warbler).
### What is your fix for the problem, implemented in this PR?
<!-- Explain the fix being implemented. Include any diagnosis you run to
determine the cause of the issue and your conclusions. If you considered other
alternatives, explain why you end up choosing the current implementation -->
Issue was introduced https://github.com/rubygems/bundler/commit/c7532ced89bbc8ddc7296c56391c1c3cc981c54a, since when `jruby` deals with urls of the form "uri:classloader", it has a weird inconsistency where `Pathname#expand_path` with an argument always returns `uri:classloader://` (double slash) as the canonical version of the path, while `Pathname#expand_path` without an argument always returns `uri:classloader/` (single slash) as the canonical version of it.
```
Pathname.new("uri:classloader://foo/bar").expand_path
# => <Pathname:uri:classloader:/foo/bar>
Pathname.new("uri:classloader:/foo/bar").expand_path
# => <Pathname:uri:classloader:/foo/bar>
Pathname.new("foo/bar").expand_path("uri:classloader://")
# => <Pathname:uri:classloader://foo/bar>
Pathname.new("foo/bar").expand_path("uri:classloader:/")
# => <Pathname:uri:classloader://foo/bar>
```
That makes `Pathname#relative_path_from` (introduced with the offending commit) explode because we end up passing to different "uri:classloader" kind of paths to it.
I believe this should be fixed in `jruby` be doing either or both of the following things:
* Make `Pathname#expand_path` return consistent versions of "uri:classpath" paths.
* Make `Pathname#relative_path_from` support different versions of "uri:classpath" paths, since they are both absolute paths after all.
But I'm workarounding the issue in `bundler` by adding an extra `expand_path` call at an appropriate place to make sure that the URLs we pass to `Pathname#relative_path_from` have a consistent shape.
Fixes #7598.
NOTE: We currently don't have the ability to run a full test suite for every PR on jruby because it's too slow (#4796 attempted to improve that but it was never completed), and it doesn't even fully pass (#7603). As an alternative, I'm adding some realworld bare tests to be run under jruby, just to make sure common tasks like this one work.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7619: [docs] Update CodeClimate link. r=deivid-rodriguez a=duckinator
This PR updates the CodeClimate link in `doc/contributing/HOW_YOU_CAN_HELP.md`, now that #7581 ("Update CodeClimate to use correct repository") is resolved.
Co-authored-by: Ellen Marie Dash <me@duckie.co>
|
| | | | | |
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7621: Update GitHub URLs in error messages. r=colby-swandale a=duckinator
This PR updates URLs pointing to the old repo in various error messages.
Co-authored-by: Ellen Marie Dash <me@duckie.co>
|
| | |/ / |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7620: February man pages r=deivid-rodriguez a=deivid-rodriguez
<!--
Thanks so much for the contribution!
If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.
To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->
### What was the end-user or developer problem that led to this PR?
No actual issue, just keeping the man pages current because the `build:check` task is failing.
### What is your fix for the problem, implemented in this PR?
Run `bin/rake man:build`.
<!-- Explain the fix being implemented. Include any diagnosis you run to
determine the cause of the issue and your conclusions. If you considered other
alternatives, explain why you end up choosing the current implementation -->
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7609: Simplify arguments to `sh` r=deivid-rodriguez a=nobu
Get rid of escaping and splitting shell code repeatedly.
### What was the end-user or developer problem that led to this PR?
No changes for the end-users.
### What is your fix for the problem, implemented in this PR?
As `built_gem_path` in `install_gems` is not escaped, this may fix a trouble in the case the argument have shell special characters.
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
|
| |/ /
| |
| |
| | |
Get rid of escaping and splitting shell code repeatedly.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7608: Merge 2.1.4 changelog r=deivid-rodriguez a=deivid-rodriguez
<!--
Thanks so much for the contribution!
If you're updating documentation, make sure you run `bin/rake man:build` and
squash the result into your changes, so that all documentation formats are
updated.
To make reviewing this PR a bit easier, please fill out answers to the following questions.
-->
### What was the end-user or developer problem that led to this PR?
The problem is that the changelog is up to date on 2-1-stable, but not in master.
### What is your fix for the problem, implemented in this PR?
My fix is to bring it up to date.
Closes #7607.
Co-authored-by: David Rodríguez <deivid.rodriguez@riseup.net>
|
| | | | |
|
