Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minitest::Reporters issue blocking update of Minitest to 5.10.0 #7

Closed
jdickey opened this issue Dec 1, 2016 · 2 comments
Closed

Minitest::Reporters issue blocking update of Minitest to 5.10.0 #7

jdickey opened this issue Dec 1, 2016 · 2 comments
Assignees
Labels

Comments

@jdickey
Copy link
Contributor

jdickey commented Dec 1, 2016

When issue minitest-reporters/minitest-reporters#219 is resolved and a new build of their Gem pushed, we should update minitest to 5.10.0 or whatever the current build on RubyGems is.

(expression of intense frustration redacted)

@jdickey jdickey added the vendor label Dec 1, 2016
@jdickey jdickey added this to the Gem Release Dot-Next milestone Dec 1, 2016
@jdickey jdickey self-assigned this Dec 1, 2016
jdickey added a commit that referenced this issue Dec 1, 2016
But see Issue #7; the poseurs at Seattle.rb pushed out a minor update
to `minitest` (5.9.1 => 5.10.0) that broke `minitest-reporters`. You
expect a changelog? What's that?!?

20 tests, 21 assertions, 0 failures, 0 errors, 0 skips
Coverage: 152 / 152 LOC (100.0%) covered.
RuboCop: 18 files inspected, no offenses detected
Flay: Total score 0
Flog: Total 0.0; method average 0.0 # No actual methods per se in this code
Reek: 0 warnings
@zenspider
Copy link

I just released minitest 5.10.1 to patch this up until this gets fixed properly in minitest-reporters.

Is that second paragraph really necessary? Does pretending to quote me with something I've never said honest or fair or even remotely accurate? Does it make you feel better?

@jdickey
Copy link
Contributor Author

jdickey commented Dec 3, 2016

@zenspider Apologies. That was written at the very end of a long, stressful day and the wording was less than professional. It does, however, express my experience in trying to follow how you folks do releases. I've looked at your repos for years; while you have great tools and perform an unreservedly important service to the community, people who are familiar with community standards (SemVer, GitHub issues and release tagging, etc.) find them incomprehensible. Many people, likely including yourselves, have jobs that soak up most of their available cognitive resources, and GitHub has some great resources to help projects help people figure out productive ways to contribute without totally immersing themselves in the innermost lore and arcana of projects. People can actually propose bugfixes if the walls to such contribution are not unduly raised; that would tend to reduce your workload, wouldn't it?

Second paragraph is gone. Thanks for the fix, and the feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants