Patching the cloud on a Tuesday night means I get Wednesday morning to run my tests to see if anything is broken. Wednesday afternoon create a support ticket. That gives Epicor 2 days to acknowledge the ticket, then assign someone. Then start the back and forth work on duplicating or further explaining the issue. I would like to see a minimum of 5 business days. I don’t track the exact amount of idle time between steps but 2 days to work thru an issue doesn’t seam realistic or are these minor patches not worth the worry?
1 Like
I hope so, as we’ve done zero testing for them for the past 7 years.
2 Likes
In my experience, the minor patches are welcome and the cadence is appreciated. With 2024.2 , much was broken with the .2 release and the minor patches are making the system more stable. I see less need to test every update, but increasingly (especially with 2024.2) the need to spend more time testing releases.
2 Likes
As others mentioned, the point updates are usually fine (knocks on wood). It’s the major updates that need a good look over.
This holds true for lots of software! The three-number version pattern (ie, 2024.2.4 or Version.Patch.Fix) gets drilled in as (Eventually.Always.Only if we have to).
2 Likes
“Are 3 business days enough to test a patch”. Nope. Good thing they tell us not to bother. What could go wrong?
4 Likes
Thanks for the feedback,
I’m going to just do simple testing. Printing daily forms. Quotes, Quote Worksheet, Traveler, PO, PS, BOL, Invoice, Timephase rpt, Scheduling Rpts.
I don’t like Monday morning fireworks, will sleep better Sunday night.
2 Likes
That’s prudent and should suffice.