Add the ability to revert Extension versions

Jennifer_Kunz

MVP

29-04-2019

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

1742725_pastedImage_0.png

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.

9 Comments (9 New)
9 Comments

gflare

30-04-2019

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.

josed30633309

03-05-2019

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.

michaels8791510

13-05-2019

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.

thomas_amsler

15-05-2019

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

thebenrobb

Employee

30-05-2019

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 😃

Jennifer_Kunz

MVP

30-05-2019

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?

thebenrobb

Employee

31-05-2019

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 😃

thomas_amsler

04-06-2019

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.

thebenrobb

Employee

18-02-2020

 
Status changed to: Accepted