Allow attr_encrypted version four

[mjankowski]

As of version 4.0.0, attr_encrypted supports Rails 7.

This change relaxes the version requirement for attr_encrypted so that there's a path to upgrade to Rails 7 while staying in the devise-two-factor 4.x series, for apps who are ready for the Rails update but not yet ready for the devise-two-factor 5.x update.

Relevant attr_encrypted version: attr-encrypted/attr_encrypted@b565876
Rails 7 changes: attr-encrypted/attr_encrypted#434

Related - #226

Opening this to start discussion and to kickoff the CI version matrix and see how it looks.

One thing I'm not sure about re: versioning here is how the internal method renaming that happened in attr_encrypted for Rails 7 support interacts with the gemspec requirements. I've started by changing < 4 to < 5 in the gemspec (presumably would bump this gem to 4.0.3?), but possibly changing the whole line to only allow ~> 4.0 is more appropriate (and maybe bump to 4.1.0?). Thoughts appreciated on that front ... happy to add doc changes or other version changes here as needed.

[caiofct]

Hey there. Getting this PR merged would really benefit us since we are working in a Rails 7 upgrade but don't want to migrate to devise-two-factor 5.0.0 at the same time to reduce the chances of regressions, especially given this is such a critical piece of the app.

Any chance we can have this merged soon? Anything I could help with?

[mjankowski]

I just pushed another commit which changes the spec to run conditionally based on which version of attr_encrypted is loaded, which should allow for older versions to run specs correctly as well as newest.

[mjankowski]

@bsedat - you have most recent commit ... are you still maintaining this gem?

Would love some guidance on what approach to take here and how to get this merged. Let me know if my previous comment about how to handle the version changes wasn't clear. I'd love guidance from a maintainer on which approach to take and then I'm happy to make the changes.

[bsedat]

@bsedat - you have most recent commit ... are you still maintaining this gem?

Would love some guidance on what approach to take here and how to get this merged. Let me know if my previous comment about how to handle the version changes wasn't clear. I'd love guidance from a maintainer on which approach to take and then I'm happy to make the changes.

I won't be able to test changes in any live Rails apps but I'm fine to merge into the v4.x branch since it seems like encrypted_attributes is the only breaking change according to the attr_encrypted release.

@mjankowski Let me know if you can try it out in your own Rails app and then I can work on perhaps doing a proper gem release. In the meantime you can have bundler pull v4.x source directly from Github.

[mjankowski]

I won't be able to test changes in any live Rails apps but I'm fine to merge into the v4.x branch since it seems like encrypted_attributes is the only breaking change according to the attr_encrypted release.

Sounds good -- and yes, from what I can tell it's only that internal method rename they needed to do for the attr_encrypted version bump, and that's not even directly relied on (only in specs) for devise-two-factor, so it seems safe.

@mjankowski Let me know if you can try it out in your own Rails app and then I can work on perhaps doing a proper gem release.

As of now I have this WIP PR to update Mastodon to Rails 7 - mastodon/mastodon@ace9a42 - and while there are still unrelated things to resolve there, pointing to my PR branch here was sufficient to allow the upgrades, and specs all still pass, etc.

In the meantime you can have bundler pull v4.x source directly from Github.

Thanks, that would be great, and feel less brittle than pointing at a PR branch.

[caiofct]

Any chance we could get a new gem release after this one has been merged into the v4.x branch?

[bsedat]

Any chance we could get a new gem release after this one has been merged into the v4.x branch?

Pushed v4.1.0.

[mjankowski]

Thanks!

[caiofct]

Thank you!