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

Update activesupport to 6.0 #45

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

EverybodyKurts
Copy link

Update activesupport to 6.0. #44

@@ -1,13 +1,10 @@
language: ruby
rvm:
- 2.2
- 2.3
- 2.4

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought activesupport ~> 6.0 requires ruby 2.5 or above.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I didn't know that.

- gem install bundler

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is not relevant and should be done in separated PR.

@@ -11,10 +11,10 @@ Gem::Specification.new do |gem|
gem.test_files = gem.files.grep(%r{^(test|spec|features)/})
gem.name = "time_difference"
gem.require_paths = ["lib"]
gem.version = "0.7.0"
gem.version = "1.0.0"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is not relevant and should be done in separated PR/commit.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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/

Copy link
Author

@EverybodyKurts EverybodyKurts Oct 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"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.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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

Successfully merging this pull request may close these issues.

2 participants