Comment 6 for bug 1057183

For clarification only of the original intent of eg_version, it was meant to be used as a per-instance troubleshooting datum. Say a site had over time, locally backported several DB-level fixes, one could tell not only at what time (which is indicative of, but not declarative about), but specifically which version they were running when the backported update was applied.

For sites that always runs only full releases (which hopefully will become more common, but is not the rule yet) this is less important, but IMO still useful. For parity with with the intended use, I would agree with Bill, that the applied_to should be set to the new version only at the very end of the upgrade.

Doing that would also allow us to move towards a smarter upgrade process (building, likely, off the update_db.sh dev tool) so that partial upgrades can be repaired and restarted from whatever point they reached, instead of potentially failing near the end of a big, multi-hour mostly-single-transaction SQL script.

As for deprecation and supersesion, a likely use case is one where the version upgrade script is, effectively, an upgrade chunk script that supersedes the version-intermediate chunk scripts that do things like fire off re-ingests, so that those expensive, recurring data-update processes only happen once at the end when you're doing the X-to-Y all-at-once upgrade, instead of trying to follow master.

Does that help, and/or make sense?