So cloud and on prem are diverging into two separate products? This information is quite confusing. What does the word “can” mean in this context? Cloud customers can decide to only get feature updates once per year if desired? Will cloud get any of the dot releases? What is the naming/numbering of the monthly releases for cloud and will the dots be tied to those monthly releases or back to the main .100 release? Will you have to install all of them or will they be cumulative like they are now?
Nope.. One Product. It is just that Cloud will be able to receive monthly upgrades. Those monthly upgrades include new features as well as patches (Updates). all year long, those same things will be consolidated into the annual build 100. And Build 100 will be the “big” release where major enhancements that are not compatible with monthly releases will take place (schema changes, big database changes, framework changes). The monthly releases, will be more like what Development currently calls the current code branch, which includes everything that they are working on… but the release will only include what has been tested, documented, and approved for release.
Not trying to be a smart-alec, but would this not be CI/MD for cloud users and not CI/CD? I’m used to CI/CD delivering continuously and then have features lit up via a flag, sometimes in rings so if issues are found early then can be backed out if necessary.
So if an on premise customer discovers a bug and support says its fixed in the next monthly release, the on premise customer is just SOL for a year?
That’s one way to strong arm on-prem customers to the cloud.
I am reading this as the monthly updates that are cloud specific are more about feature enhancements and that is what on-prem is losing from those (not really losing since what we are really losing is the 2nd feature update for the year since we are going to a single release, just didn’t have a better word), we need to wait until the yearly update to get any new features where as cloud will be able to get them monthly. @timshuwy still references the bi-monthly updates which I imagine will still include/be focused on bug fixes as they are now.
Maybe I am wrong but I just can’t see Epicor (or any other company TBH) deciding that it will not issue bug fixes to their customers.
They already do this and have for a couple years. There’s several posts on here about Epicor not providing fixes for versions under active support. They tell you to just upgrade to get the bug fix.
I realize that, and have been bitten by it myself, but there is a big difference between ‘some issues must wait until a feature release’ and ‘all issues must wait until a feature release’.
True. Guess we will see what happens. I’m not overly optimistic. The track record lately hasn’t been great.
I am constantly in this situation now so yeah I can see it lol. At this very moment, there is a bug that is fixed in 2025.2.15. Gov cloud is not going to receive this release because . . . reasons. Development refuses to provide a hotfix.
Mark, you are correct… we are going from 2 releases per year to 12 monthly… not quite the endpoint for pure “continuous” delivery, but we are taking baby steps towards that. we had to restructure our pipeline to accomodate monthly, which gets us a whole lot closer to the ideal. We had to also implement true feature flagging which is still in the build process (you may have seen some previews of this).
intended here…
This now puts the onus on your cloud customers to find sufficient time to test 12 releases a year instead of 2.
Honestly, this should be no different than the monthly patches, no? Some might say we shouldn’t have to test patches, but…
@aosemwengie1… I promise there’s no conspiracy here 
On-prem customers are not losing bug support. We are still delivering bi-weekly patches for defects, same as we always have. If support says a bug is fixed in an upcoming monthly release, that fix should also be available via patch (there are possible exceptions). They are not waiting a year for bug resolution.
What has changed is feature delivery cadence. On-prem will get one major release per year (Build 100), while cloud receives features monthly. Those cloud-delivered features are then rolled up into the next on-prem release.
So the distinction is simple:
- Bugs → continue to be patched regularly (no change)
- New features → consolidated annually for on-prem (intentional change)
This is about aligning delivery models, not penalizing on-prem customers.
That is exactly our goal… they should work just like the monthly patches, except some new non-breaking features.
Fair. Everything should be tested to a degree…but realistically patches are supposed to be bug corrections…whereas releases would likely be changes of functionality.
You understand where @JMPCONJ is coming from though, I assume… the patches lately have been pretty rough for cloud customers. .16 broke a lot of things.
Oh, I do understand! I’ve never bought into the “you don’t have to test patches” theory, so it’s really not something new to me. There have always been 12 updates a year. 
Can cloud choose to receive the bug fixes without the new monthly features?
That’s exactly where my concern is coming from…having six times the chance for broken functionality causing a disruption to performance. We can’t afford downtime or lost capabilities…no one can.