Rails 6.1(2) upgrade

Development
1

Hi everyone,

TL;DR: We are working on Rails initialization process improvements and it might break plugins, sorry for that. If Foreman with your plugin don’t boot up all of a sudden, it is quite likely related, so please report it here or to me directly.

We have started to tackle the Rails 6.1 upgrade. This mainly includes enabling Zeitwerk which forces us to double down on improving the initialization process, which may disturb the plugin stability.
We are trying to think of plugins prior merging changes, but we will not think of everything.

So far we have had few breakages, thanks @tbrisker, @lzap and @evgeni for quickly finding them out and helping with fixing them.

Breaking changes so far:

  • EnsureNotUsedBy is no longer namespaced under ActiveRecord::Base - GH-8946

I’ll try my best to updage this list as we proceed.

Some big changes are still ahead of us:

  • We need to postpone plugin permission initialization
  • We need to postpone Setting inventory initialization

If you’d like to know what is going on, or help, contact me or just pick a task from the Rails 6.1 tracker :slight_smile:
If you’d like to test if your setup still works, please test niglies, we will try to keep them installable so you’d be able to test the changes as those get in.

3 Likes
2

Hey Ondrej,

I see 6.1(2) in the title. Could you outline the rough plan for the various versions to help the platform team consider potential breakages and ability to plan around them and so that packaging team can assess if they will need to build Rails 6.1 stack and then follow up by building Rails 6.2 stack (or be able to go directly to Rails 6.2) ?

3

I’m not aware of any deprecations we would hit between 6.1 and 6.2, so if everything goes smoothly, I’d go directly into 6.2, unless there is an issue we didn’t discover yet, I’ll be able to tell once we actully finish the Zeitwerk enablement and are able to boot the application on 6.2

Does that sound feasible, or should we just go 6.1 and only that 6.2?

4

If direct to 6.2 works, that would get my vote as it reduces the packaging churn. Please coordinate with @packaging as the Rails packaging can be done in parallel as a draft PR to be staged up ahead of time.