I feel like if it was only one update a year a different set of people would complain as well. Sounds more like the flex option needs additional flexibility.
The old axiom, āYou canāt please all of the people all of the timeā comes to mind.
We also chose to flex this time as well.
Regular Updates force the improvement of process and discipline within your ERP team. Exasperating I know you want to do improvements to help the business but the constant need to test for upgrade is always the priority.
Question 1: What effort/planning do people go to when itās just an update, rather that a full version upgrade?
What tools/process are people using/doing to test?
1 Like
Cloud customers only please:
- I love upgrading twice per year
- I strongly prefer a once per year upgrade cadence
- Either way is fine with me
0 voters
2 Likes
I donāt disagree. But regular doesnāt have to equate to twice per year, it can equate to once per year just as easily.
We do absolutely nothing for dot release updates. For regular upgrades, we start out scheduling/requesting testing, then devolve to begging/exhorting/pleading/bribing and finally give up any hope that testing will ever be completed and count on other customers having caught the issues.
2 Likes
Thatās a pretty dismissive thing to say about this conversation which is not baseless complaining but legitimate discussion.
2 Likes
When we live in a browser world, Iām starting to work with Playwright.dev. It does API testing for checking Epicor Functions or other REST endpoints that I have a dependency on. It does end-to-end browser sessions, on mulitple browsers, with screen captures. And this is not to just test upgrades but also for internal development.
Expecting Epicor to test every possible use case is just not possible and an unrealistic expectation.
What do other software companies do? It depends. Most web-native companies donāt do many version upgrades but add features in a controlled roll-out. Early adopters get the new stuff, file bugs, and after some time, the other users get the feature. At some point, one has to do upgrades to the database and that usually requires some downtime. Amazon, Google, and Netflix across all of their services deploy over 1000 times a day. These changes are smaller and errors show up sooner. The longer one waits to implement a feature, the more the features add up, and it creates more, not less disruption. The more often we do something, the better we get at it because it forces us to be more efficient.
With the advent of containers for Kinetic, we might be able to do the same thing someday. The feature flag infrastructure is already there. Running containers with various versions will make it easier for users to test and roll back without the drama.
3 Likes
This could also help with the begging/bullying users to pleaaassee test, as that is certainly the worst part right now.
1 Like
Note that we have already addressed this question for all future upgrade schedules. This change was already in effect for the 2024.1 scheduled release, and was discussed again just yesterday.
2 Likes
Mark, if Epicor can focus on this tool too, alongside you, that would be huge, I agree.
1 Like
This is almost exactly what I said as justification for the delay yesterday. We needed to address the problem before the problem hit production. We could not do that and go live this weekend. While we donāt like the delay, the good news is that we donāt actually have ābad newsā to report other than the delay.
2 Likes
Iām not sure the tool is as important as the mindset. Epicor maybe using a fine tool like SmartBear but we wouldnāt want to require everyone to buy a license. I could certainly see the community here sharing testing strategies and scripts using various tools out there.
2 Likes
Our upgrades are always a bit like finish work in a house. Try your best and caulk the rest.
We test 7 varieties of quote to cash and triage the rest. If we can get orders in, product out, and cash in we are good to go. Everything else is just workflow inconvenience. I think we have one āmajor-ishā breaking issue a release that doesnāt get caught and itās usually triaged the same day.
3 Likes
First Iāve heard of it, weāre still Classic but when we do get to Kinetic a tool like this would be awesome for regression testing. Thanks!
Unfortunately, the cadence schedule as designed is twice per year. While I feel you idea has merit, it is currently working as designed. Perhaps you could enter this as an idea in our ideas forum?
Whack - sorry, got into tech support mode there for a minute.
Great idea Alisa! Iād be a loud supporter of once per year!
1 Like
I canāt help but think of all the procedures we do only once a year, physical inventory, year-end close, tax filing, open enrollment, audits, ā¦, and how good we are at doing them.
3 Likes
I would take fewer features with more stability 10 out of 10 times.
5 Likes
And I would take fewer features more often for stability all year round.
BTW, Iām not trying to be a 
(comes naturally), but I did an Insights talk a few years ago about how to roll with the cadence as an early SaaS userā¦
1 Like
So glad to see this! 
Great idea, I hadnāt thought of bribingā¦