You can clone with
HTTPS or Subversion.
I attempted with the latest but no migration still.
Will look into this when I have a moment, and will commit this and other fixes into 2.1.1 in the middle of the ocean!
Just discovered this as well. Had to upgrade to 184.108.40.206 and then update.
Part of #840
Hopefully the rest of #840 for now
Loading the latest commit over a 1.x install should force the migration now. It still needs a little clean-up to make it more generic as intended.
One small issue remains: the reset pods settings and data is leaving behind pods_framework_upgrade_2_0_sister_ids and pods_framework_upgrade_2_0_0. From testing (and retesting) the migration I discovered that one or both of those being left behind will cause at least part of the migration itself to fail.
We might as well address the "proper" way to fix the migration check before closing this. My initial changes were a quick-n-dirty solution to get a fix for 2.1.1 quickly. At this late stage I think we can live with case-by-case workarounds for a few more days.
The reinstatement of the upgraded property and the check against pods_framework_upgraded_1_x is obviously not what was intended, with the reworking to make the upgrade checks more generic to handle an arbitrary chain of upgrades. I think what was intended is for pods_framework_version_last to be updated after upgrade, but doesn't. This means the upgrade condition is always met and I couldn't immediately see another option for determining if a particular upgrade has already been performed.
Fixed by @pglewis already, but when we need to run upgrades in the future for 2.2+ we'll revisit upgrades and revitalize it with some better tracking via #904
Ran into this issue on a site that had PODS upgraded, we have been able to downgrade to 1.11, but don't want to leave it there. What is the ETA on the 2.1.1 release?
It's holding for the remaining issues to be closed out: