Conversation
| rvm: | ||
| - 2.2 | ||
| - 2.3 | ||
| - 2.4 |
There was a problem hiding this comment.
Do you need to delete these versions? We still can support them, I guess. Ruby 2.2 in unsupported anymore, but 2.3 and 2.4 are supported by MRI.
There was a problem hiding this comment.
I thought activesupport ~> 6.0 requires ruby 2.5 or above.
|
|
||
| before_install: | ||
| - gem install bundler No newline at end of file | ||
| - gem install bundler |
There was a problem hiding this comment.
This change is not relevant and should be done in separated PR.
| gem.name = "time_difference" | ||
| gem.require_paths = ["lib"] | ||
| gem.version = "0.7.0" | ||
| gem.version = "1.0.0" |
There was a problem hiding this comment.
This change is not relevant and should be done in separated PR/commit.
There was a problem hiding this comment.
Isn't it a breaking change though? I guess I should either keep the gem version or the activesupport version the same. If I bump up active_support to be 6.0, that's a breaking change for people who still want to remain on rails 5.2.
There was a problem hiding this comment.
Yes, but for alpha versions (0.y.z) there are breaking changes in minor version, not major. 1.y.z is stable release, it's pretty big move. Please, read https://semver.org/
There was a problem hiding this comment.
"MINOR version when you add functionality in a backwards compatible manner"
This wouldn't be backwards compatible for people who wanted to stay on rails 5.2 and not upgrade to rails 6. Upgrading from rails 5 to 6 is a pretty huge move.
Regardless, we could specify the activesupport dependency as >= 5.1, then bump up the minor version and still keep rubies 2.2 to 2.4 in the travis build config.
There was a problem hiding this comment.
I meant this: https://semver.org/#spec-item-4
0 major version is not regular major version that should be increased with any backwards incompatible change.
There was a problem hiding this comment.
The latest commit to hit master was almost 2 years ago! I think the api is pretty stable now. I guess this gem could be kept to 0.x ad infinitum.
Anyway, would specifying the activesupport as >= 5.1 and keeping the gem version to 0.x satisfy you?
There was a problem hiding this comment.
The latest commit to hit master was almost 2 years ago! I think the api is pretty stable now. I guess this gem could be kept to 0.x ad infinitum.
Okay, but anyway, I believe that version should be changed in separated commit (with tag) by maintainers.
Anyway, would specifying the activesupport as >= 5.1 and keeping the gem version to 0.x satisfy you?
This is good idea while the gem works with lower versions of dependencies.
2 participants
Update activesupport to 6.0. #44