Add migration versioning via Migration subclasses - #21538
Conversation
|
r? @chancancode (@rails-bot has picked a reviewer for you, use r? to override) |
713a87c to
483ef3a
Compare
There was a problem hiding this comment.
mb use ? subclass.include Compatibility::Legacy
3916985 to
060f1ce
Compare
|
LGTM. I guess the main things to point out is the difference between upgrade strategies, namely this vs this. I think the strategy in this PR is easier. But, FWIW, both PRs generate a superclass, so we can switch to the strategy pattern in #21037 at pretty much any point if we need to. The other thing is that this PR doesn't support deriving the version from the file name. IMO the syntax proposed here is pretty unoffensive, so I'm not sure if we still want / need to derive this from the file name. I think the main hurdle here is that we need to figure out if the filename stuff is still required. |
|
I'm happy enough with the superclass having the version identifier. Don't need the filename to include it too, imo. This is actually a pretty elegant solution. |
060f1ce to
ddea354
Compare
matthewd
changed the title
ddea354 to
77f5580
Compare
77f5580 to
ab78694
Compare
If we use a real version, at best that'll be an onerous update required for each release; at worst, it will encourage users to write new migrations against an older version than they're using. The other option would be to leave these bare, without any version specifier. But as that's just a variant spelling of "4.2", it would seem to raise the same concerns as above.
Apart from specific versioning support, our tests should focus on the behaviour of whatever version they're accompanying, regardless of when they were written. Application code should *not* do this.
.. it also showed a deprecation warning, but we obviously needn't retain that.
Even though this means more things to change when we bump after a release, it's more important that our examples are directly copyable.
ab78694 to
97c7716
Compare
Add migration versioning via Migration subclasses
|
🤘 |
7 participants
This PR implements the migration versioning infrastructure, and restores the previous default on
timestamps null:(when in 4.2-compatibility mode).