Add the ability to revert Extension versions

[#1]

Currently, when you upgrade an extension, you get this notice:

This has scared quite a few clients off of upgrading, because there really is NO going back. Especially for Adobe extensions, there is a strong need to be able to revert in case of issues (not to be snarky, but appMeasurement/VisitorID code updates have a history of finding major problems in the first month after release). Issues like Re: What are possible reasons why ClearVariable fails? make it clear why someone may want to move back. If you upgrade and you do see something break in staging during testing, you'd have no way to go back/compare/undo.

[#2]

To add on to this; I really wish that every update had some sort of release notes.  There have been AA and ECID extension updates with absolutely no release notes.  We don't know if there was a fix to an issue, or a change in the way the extension behaves.

Even if you hunt for release notes; the Adobe Launch Release Notes pages and the Experience Cloud Release Notes pages do not always give info.

[#3]

I am currently recommending clients not to upgrade until we have assessed the risk of going for it. If the option of revert the upgrade existed, the risk of testing this out will be minimal.

[#4]

This is a major point. Right now, we have to resort to having a separate sandbox account so we can test for 1st level effects of these upgrades. That said, we do not always have time to do that, which means we delay/defer upgrading as long as possible.

Tools upgrades are a major concern for us as we have custom code in the analytics extension which could run into issues depending upon what changes happen in the tool being upgraded.

[#5]

As the OP of the linked thread I fully agree that this is a much needed feature!

[#6]

A little insight into the history of this one.

We considered this as part of the scope of the initial ability to upgrade extensions, but it is really difficult when you dig in.  An example scenario:

1. You update to the new extension version
2. You update 5 rules that are tied to the new extension version
3. You downgrade the extension
4. You now have 5 rules that are tied to an extension that doesn't exist

Now any builds that include those rules fail, you have to go find each rule and update it again to tie it to your newly downgraded extension version.

This is one scenario that causes problems, there are others.  I believe that they are solvable, we just haven't prioritized them yet. Get more votes if this is the one you want us to solve next =)

[#7]

That makes sense. But most of the time, extension upgrades do not directly affect any of the things users are asking the extension to do- they're for bug fixes, or minor UX enhancements, etc.
For instance, if I'm on Adobe Analytics Extension 1.7.2, and set prop7 to some value in one rule, then upgrade to 1.7.4 and set prop7 in some other rule... the fact that one change was made on one version and the other change was made on a newer version matters nothing to me as a user (though I get that it MAY matter to the backend). Kinda like how Extension configuration works- if I upgrade my Analytics extension's global settings (like RSID, or doPlugins), that change affects all of my rules, not just the rule I made changes to after I made after the upgrade. I'd expect a change to an extension to be similar.

Perhaps the Version numbering system can be some sort of indicator- upgrading from 1.7.4 to 1.7.5 isn't expected to make any changes to how rules/actions/etc would be set up, so there is a easier rollback option, but upgrading from 1.7.5 to 2.0.0 might require major changes and be less revertable?

[#8]

All true, and the keywords there are "most of the time".  In your scenario, any rules you saved while 1.7.4 was installed are tied to 1.7.4.  If you then downgrade back to 1.7.2, those rules are tied to an extension (by ID) that no longer exists, so we need a graceful fallback.

Once there's a graceful fallback, it would really suck for you to have to go resave all the rules you had touched while 1.7.4 was installed, so we're not doing that.  But that means that any of the rule settings you saved under 1.7.4 now have to be validated against the schema from 1.7.2.  If that fails, we have no choice but to make you go look at the resource to fix it (update to settings that validate, revert to previous settings, etc).

You're exactly right that "most of the time", it's no problem at all.  But we need to do it in a way that when it is a problem, we don't leave your property in an unrecoverable state.  Some of those pieces are actually in place now (the graceful fallback from 1.7.4 to 1.7.2, Compare View lets you revert settings), but there's just more work to lay the groundwork and connect the dots.

None of this should be interpreted as "we can't do it", just to explain why it's trickier than it looks on the surface. The story carding sessions for this stuff makes my head hurt =)

[#9]

Thanks for the insight. As a java developer and also using node I know how dependencies can be a pain and need to be checked for each up or downgrade.

In our case I created most of the rules with 1.7.1 or 1.7.2 and they worked with 1.7.4, except the issue I mentioned with the clear variables bug. So in my case a rollback to 1.7.2 should have been easy. But yeah, rules I modified since I upgraded the extension could theoretically cause problems.

[#10]

We found a new cookie being set when a recent upgrade, a no-no for our privacy team.  We cannot revert to remedy the issue, which is a major, major pain point for us. 

Extension Upgrades | Adobe Data Collection

Ben, when will this functionality be added.  

Best,

Enrique