updog: only remove known extensions from migration filenames #662
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If we always set_extension, it removes anything after a period. If the
migration does not happen to be named with an extension, then the only period
is in the version number, so we change "migrate_0.1_foo" to "migrate_0", which
is not a valid migration filename. The migration won't run and the upgrade
will fail.
With this change, we only remove the extension (.lz4) that matches our
compression format.
Migrations downloaded by older updog could not have an extension because it
would not be removed and would again be invalid, so unfortunately we have a
diverging path. Versions before the addition of set_extension (let's call them
version A) cannot have an extension, and versions with set_extension but
without this change (let's call them version B) must have an extension, which
means that update manifests need to list special copies of migrations that have
an extension for any paths leading in/out of that intermediate version B. This
must be maintained until version B is no longer supported.
If we call releases including this change "version C", then here's an example
set of updates to work around this issue:
As long as B is supported, each new version will need a special path from B.
For example, after releasing version D:
Testing done:
Before, when updating to a new test version, I had a migration named "migrate_0" that did not run because it didn't have a valid name, so my update failed.
After, I have the right name:
The migration ran properly and the update was successful.