validates_timeliness
validates_timeliness copied to clipboard
Support Rails 7
@mitsuru Rails 7 deprecates this line: https://github.com/adzap/validates_timeliness/blob/master/lib/validates_timeliness/railtie.rb#L5
Should be replaced with
ValidatesTimeliness.default_timezone = ActiveRecord.default_timezone
Thanks @mitsuru
@adzap could you take a look at this PR to support rails 7?
Thanks @mitsuru
@mitsuru Thanks for addressing this!
@adzap These changes LGTM. Would you be able to 👀 and get a new version out that includes them? Thank you 🙇
Thanks @mitsuru
@adzap please look at this PR
LGTM.
Should we expect major changes in Rails 7.1 in regards to these changes?
If not, we could change the requirements to < 8
, as I suspect changes that may break behaviour would be deprecated in 7.1 and removed in 8.0, as has been the pattern recently?
Furthermore, we COULD add in ruby 3.1 specs for Rails 7, in the "Support newest versions" mindset?
Bump? Somebody forget about the PR? :)
Furthermore, we COULD add in ruby 3.1 specs for Rails 7, in the "Support newest versions" mindset?
Hi, I also think that Ruby 3.1 should be added to the test matrix
What's the status of this, I cannot upgrade to rails 7 because this blocker. Thanks.
@fabn -- I'm using gem "validates_timeliness", github: "mitsuru/validates_timeliness", branch: "rails7"
@fabn -- I'm using
gem "validates_timeliness", github: "mitsuru/validates_timeliness", branch: "rails7"
I understand but it's a little bit fragile for a production deployment. I think I'll try if it works but then I'll fork it to have control on what's happening.
Yeah, ngl, I'm getting slightly annoyed too. I'm considering switching to @mitsuru's version, and maybe pegging to that commit to reduce fragility. I'm just worried I'll forget about it over time and not get updates when official validates_timeliness
updates.
Does anybody know of a simple way to check at runtime whether a new version of validates_timeliness
is available on rubygems? I don't want to spawn a command, and I want to be able to generate a Sentry event, so I get an email and know to make the change even if I'm not working on the project at that moment.
I think we all want this to be updated. When I'm in these situations, for better or worse, I find a supported fork, peg the ref to a specific commit if I'm concerned that the fork author isn't super trustworthy, and then I subscribe to the Github issue (i.e. this one), because it's likely to be closed if this ever gets resolved. For what it's worth, it works for me.
@ariccio - you bring up a good question. I think you could write a script quite easily using output from bundler outdated
and show/notify via CI, Sentry, or a million other ways. If that doesn't exist, already, it sounds like a very useful tool.
WELL, I spent 3 hours trying to learn how to make set-output
in GitHub Actions work, and if it did, I could auto-create an issue or something when the repo updates. But After 3 hours trying to learn year another DSL, my head is broke.
If anybody else wants to take a crack at it, fork or PR: https://github.com/marketplace/actions/check-validates_timeliness-new-version
In case anybody is interested, I found a solution that works with a git pre-push hook and lefthook. You can pull down a working script here.
Any news on getting this merged?
I was briefly very confused when my pre-push hook failed, saying Possible new version validates_timeliness available: 6.0.0
, thinking I unwittingly broke something, but I think it's actually been merged and released!!!
Thanks, @adzap! Hope all is well.
Hrmph. #221 is still blocking.
Bundler could not find compatible versions for gem "activemodel":
In snapshot (Gemfile.lock):
activemodel (= 7.0.4)
In Gemfile:
geokit-rails was resolved to 2.3.2, which depends on
rails (>= 3.0) was resolved to 7.0.4, which depends on
activemodel (= 7.0.4)
validates_timeliness (>= 6.0.0) was resolved to 6.0.0, which depends on
activemodel (< 7, >= 6.0.0)
Deleting your Gemfile.lock file and running `bundle install` will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict.
Thanks, but there was a bit too much in the PR and also didn't conform to the convention of using major version per ActiveRecord major version. I have pushed necessary commits and released a beta.
Thanks! Hope all is well outside your FOSS life 😊.