Upgraded to ruby 3.1.4

[ConnorSheremeta]

Upgraded to ruby 3.1.4 with necessary changes

[pgwillia]

Are you still planning to do this in steps?

#3091 (comment)

I'll look for the release prep PR before signing off on this one.

[ConnorSheremeta]

#3096 has the prep for the release while still maintaining a functioning app. The short-hand hash syntax changes here was introduced with ruby 3.1 which give errors on 2.7.

[ConnorSheremeta]

Unsure why CI still has this check that is stuck on expected? I believe I removed all references to 2.7 in push.yml... maybe this will go away when this PR is merged?

[pgwillia]

Unsure why CI still has this check that is stuck on expected? I believe I removed all references to 2.7 in push.yml... maybe this will go away when this PR is merged?

This check is stuck because it's one of our branch protection rules. Let's drop this check after we've started deploying with Ruby 3.1, in case we need a quick security release.

I was imagining the steps you were following

• prep jupiter 2.4.5 to work with 2.7 and 3.1
• release jupiter 2.4.5 -- communicate with Beau and Sean
• deploy with ruby 2.7
• deploy with ruby 3.1
• complete transition of jupiter code to Ruby 3.1 via merging this PR
• release jupiter 2.5 -- communicate with Beau and Sean
• deploy with ruby 3.1, don't look back

[pgwillia]

#3096 has the prep for the release while still maintaining a functioning app. The short-hand hash syntax changes here was introduced with ruby 3.1 which give errors on 2.7.

I wasn't clear, sorry. I meant the jupiter version bump PR with a commit like this. To prepare for cutting a release.

[ConnorSheremeta]

Unsure why CI still has this check that is stuck on expected? I believe I removed all references to 2.7 in push.yml... maybe this will go away when this PR is merged?

This check is stuck because it's one of our branch protection rules. Let's drop this check after we've started deploying with Ruby 3.1, in case we need a quick security release.

I was imagining the steps you were following

• prep jupiter 2.4.5 to work with 2.7 and 3.1
• release jupiter 2.4.5 -- communicate with Beau and Sean
• deploy with ruby 2.7
• deploy with ruby 3.1
• complete transition of jupiter code to Ruby 3.1 via merging this PR
• release jupiter 2.5 -- communicate with Beau and Sean
• deploy with ruby 3.1, don't look back

Unsure why CI still has this check that is stuck on expected? I believe I removed all references to 2.7 in push.yml... maybe this will go away when this PR is merged?

This check is stuck because it's one of our branch protection rules. Let's drop this check after we've started deploying with Ruby 3.1, in case we need a quick security release.

I was imagining the steps you were following

• prep jupiter 2.4.5 to work with 2.7 and 3.1
• release jupiter 2.4.5 -- communicate with Beau and Sean
• deploy with ruby 2.7
• deploy with ruby 3.1
• complete transition of jupiter code to Ruby 3.1 via merging this PR
• release jupiter 2.5 -- communicate with Beau and Sean
• deploy with ruby 3.1, don't look back

Would those first two deployments just be on staging or all the way to prod? I'm trying to work out what benefits there would be to deploy three times with two version bumps rather than doing it in one version bump and one deployment after this is merged which is what I had envisioned.

[pgwillia]

I was imagining the steps you were following

• prep jupiter 2.4.5 to work with 2.7 and 3.1
• release jupiter 2.4.5 -- communicate with Beau and Sean
• deploy with ruby 2.7
• deploy with ruby 3.1
• complete transition of jupiter code to Ruby 3.1 via merging this PR
• release jupiter 2.5 -- communicate with Beau and Sean
• deploy with ruby 3.1, don't look back

Would those first two deployments just be on staging or all the way to prod? I'm trying to work out what benefits there would be to deploy three times with two version bumps rather than doing it in one version bump and one deployment after this is merged which is what I had envisioned.

The benefit of the two version bumps is being able to roll back if any changes cause issues. There are two places I can see where we could potentially run into issues:

• current changes in Jupiter (rack, rails, crawl delay, compatibility with Ruby 3.1)
• changing the Ruby version

Suppose it's the first; we could revert to jupiter 2.4.4 and fix bugs before trying the ruby upgrade. If it's the second, we could back the Ruby version and troubleshoot before continuing. The disadvantage to combining both changes is that it will be more difficult to rule out where the bug originated.

I misunderstood your vision. Whatever you and Beau work out for deploying is fine by me. Do you have permission to change the branch protection rules?

[ConnorSheremeta]

Makes sense, I feel like your approach is the way to go. I've pushed up a PR here for the 2.4.5 release. Yes, it does look like I have permission to change the branch protection rules

[pgwillia]

[pgwillia]

👍