Last night a ‘minor’ patch update was applied to our Pilot and Education environments.
I’ve been told that these are applied monthly and that there is no need to test them, as they’re designed to be non-disruptive.
However, we had a a first training day today with our implementation team, and the update had broken a significant number of things in both environments.
Several Trackers and Entry screens wouldn’t load all, and we were seeing errors like below on display headers, field captions and in menus.
To me, this definitely falls into the realms of ‘disruptive’ but I’m wondering if this was just bad luck. Have you experienced these sorts of errors with previous monthly patch updates? Can we really skip testing for these updates?
(I don’t really want to be investing resource into fully testing on a monthly basis. However, I’d prefer to be realistic).
Normally, I would agree with Epicor. When we went live on the Public Cloud for 10.2.100, the monthly patches were stable. We still did a walk-through of basic functions but rarely, if ever, did we see a breaking change. I know they’ve happened to others though.
But in the Kinetic world, there are just too many new things happening to not do some checking. I think you are being prudent in doing some testing until proven otherwise. I’m not certain that a full regression test is required every month like a .1 → .2 update. That’s just my opinion.
Unfortunately this is something that you’re going to have to get used to. We’re a new cloud customer as well and have tried to adopt Kinetic from the beginning because we don’t have years of Classic experience/habits to break. That was a HUGE mistake. The development team at Epicor doesn’t take any steps to validate their software before pushing it out and new bugs and glitches are just a way of life and something you need to be prepared for with every update & release.
Epicor seems to think it’s okay to change the semantics of an API without documenting it as a breaking change, just as long as you don’t change the syntax.
