I see. It seems to me that there is no way of this making people happy if the default state is that everytime you push a schema-breaking change you have to accept that you are cutting off some instances from the normal upgrade path. 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.
Aside from that, maybe there is another angle that could be worth exploring: 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? That way you could use those tags as checkpoints.
As a small aside, I am interested in anycase in messing with the tag / endpoint of the rails app because I want to perform some minor personalizations of the interface, so I will have to maintain my own fork and merge manually any changes from upstream. I'm mentioning this because it's another (imho not too uncommon) usecase that requires messing around with the rails image endpoint and tag.
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 ;-)
I see. It seems to me that there is no way of this making people happy if the default state is that everytime you push a schema-breaking change you have to accept that you are cutting off some instances from the normal upgrade path. 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.
Aside from that, maybe there is another angle that could be worth exploring: 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? That way you could use those tags as checkpoints.
As a small aside, I am interested in anycase in messing with the tag / endpoint of the rails app because I want to perform some minor personalizations of the interface, so I will have to maintain my own fork and merge manually any changes from upstream. I'm mentioning this because it's another (imho not too uncommon) usecase that requires messing around with the rails image endpoint and tag.
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 ;-)