CompatHelper: bump compat for OptimizationOptimJL to 0.4 for package test, (keep existing compat)#2353
Conversation
…test, (keep existing compat)
622e056 to
92ec34d
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2353 +/- ##
==========================================
- Coverage 86.86% 86.80% -0.07%
==========================================
Files 24 24
Lines 1599 1599
==========================================
- Hits 1389 1388 -1
- Misses 210 211 +1 ☔ View full report in Codecov by Sentry. |
|
Is there a way to open an aggregated PR for these dependencies upgrades? If not, we could contribute a feature to CompatHelper. @penelopeysm @devmotion any thoughts? |
|
That thought has struck me, but I think it's impossible for an automated tool to figure out which of the PRs are related and should be aggregated. Although grouping multiple PRs into one is fairly easy (create a new branch -> merge PRs into that branch -> open a new PR from that branch back to master), the converse problem of breaking up a PR is actually more annoying to deal with ( The closest compromise I can think of is if the same dependency is being bumped in the main package + tests, then group those. That could be an optional flag for |
Pull Request Test Coverage Report for Build 11062381193Details
💛 - Coveralls |
This pull request changes the compat entry for the
OptimizationOptimJLpackage from0.1, 0.2, 0.3to0.1, 0.2, 0.3, 0.4for package test.This keeps the compat entries for earlier versions.
Note: I have not tested your package with this new compat entry.
It is your responsibility to make sure that your package tests pass before you merge this pull request.