I don't mean to make this a ruby vs python thing, but I believe that django had a way of interleaving data changes with schema changes to make migrations repeatable even when doing all of them at once
This approach (specifically, treating data migrations as schema migrations to run them chronologically) is on the table 🙂
what if those changes triggered a major version change of forem and required people to manually change the container image tag to continue the upgrade process?
I like this idea and I really like how some libraries and frameworks (for example, Ember.js and RSpec) implement it — upgrade to the latest 2.x release, fix deprecation warnings, upgrade to 3.0. Unfortunately, our versioning scheme will be calendar-based rather than SemVer, so this wouldn't fit. Still, it's a pretty slick move if you can swing it.
Unfortunately, our versioning scheme will be calendar-based rather than SemVer, so this wouldn't fit. Still, it's a pretty slick move if you can swing it.
Galaxy brain solution: only do breaking updates once a year on January 1st and call it a major version increase ;-)
This approach (specifically, treating data migrations as schema migrations to run them chronologically) is on the table 🙂
I like this idea and I really like how some libraries and frameworks (for example, Ember.js and RSpec) implement it — upgrade to the latest 2.x release, fix deprecation warnings, upgrade to 3.0. Unfortunately, our versioning scheme will be calendar-based rather than SemVer, so this wouldn't fit. Still, it's a pretty slick move if you can swing it.
Galaxy brain solution: only do breaking updates once a year on January 1st and call it a major version increase ;-)