The other carrot vs stick I’m hearing about is that on-prem will have 10% YoY price increases for maintenance and cloud will ‘only’ be 8%… It’s not like we can easily go elsewhere, other than going off of maintenance completely.
If we went to cloud, I’d like to defer the upgrade to yearly, at least 2 months after the major version has been released. Being beta testers on a new version impacts productivity, and deferring it 8 months gives our users a more stable version with most of the work arounds already figured out by EpiCare and EpiUsers
What big update. I thought they said the big update was just the cumulation of the prior 11 mo updates cloud would have already gotten. Clarity needed.
Plus: framework/tools, schema, and other breaking changes… is my understanding at least.
I doubt it unless Epicor will be doing schema changes during monthly updates… which Epicor have promised that they won’t (along with no API changes) but that was also previously stated for minor updates and I think most of us know there were frequent exceptions to that.
It is hard to imagine that there could be many new meaningful features and functionality rollouts without schema or API changes, unless there are always placeholders added in advance, but I guess we are going to have to wait and see….
Really really hope this monthly thing doesn’t blow up. It’s a struggle just getting the user community to test once or twice a year now. There’s only so many hours that can be afforded to that process.
I’ll never buy the “shouldn’t have to test” statement. Ever. The one time you don’t is the one time it’ll detonate.
EDIT - I’ll add a qualifier to it - test critical functions. Realistically you can’t test every single thing…but end-to-end runs on sales/purchase/manufacturing orders are a must. If ANY order lifecycle breaks you can’t do business.
That is not what I heard. On the webex they said intead of releasing x features all at once in the bi-annual releases, that they would divy those up so it would be x/6 features per month every month. They didn’t promise there wouldn’t be schema changes.
Alisa is correct… there MIGHT be schema changes, but they will only be additive during the year. subtracting from the schema would not be backward compatible. we said that the chagnes during the monthly releases would be backward compatible. Same with APIs, and Screen changes. We can also add NEW screens and menu options, but during the year, we would not take away a screen or menu option.
non-backward compatible changes would be reserved for the annual release.
Just to confirm, does this mean that, in both theory and practice, a company should be able to request to roll back to a prior 2026.1XX version IF a critical/important issue is found within a newer 2026.1XX version (via support, exceptional circumstances etc.)?
If so, that would be fantastic improvement and should help to significantly reduce the risks of business impacting issues/interruptions within new versions/containers!
I think most people here, and just in general, within the enterprise systems spaces understand that systems with such a high level of flexibility and capabilities, such as Epicor Kinetic, do naturally have a high level of complexity and non-trivial amounts of change/breaking risks when even a ‘fix’ for most customers can become a new issue for some. And, therefore, some new/additional options to rollback I think would be fantastic to help mitigate and respond in such scenarios… And perhaps something to communicate more to help address concerns.
