Can someone give me a quick rundown of how to cross reference the versions? I’m expecting a 10.2.200.1 or something. I’m not sure that 3.2 refers to. This is a case that is involving customization so is it the Ice Tools Version? Is that updated separately from the from the 10.x.xxx.x upgrade patches? I’m confused…
I believe that’s the ICE tools version. I think it’s shared with other products.
any idea how to cross reference what version of ERP it corresponds to?
As best as I can tell from the docs from EpicWeb:
10.2 : 3.2
10.1 : 3.1
10.0 : 3.0
9.05 : 2.5
9.0 : 2.0
Guessing Vantage was ICE 1.0…
Version decoder ring for targets.
VERSION IN EPICCARE | ACTUAL VERSION:
NOTE:
For the full version number of 10.x.y.z,
10.x is the VERSION
10.x.y is the RELEASE
10.x.y.z is the POINT UPDATE
Why do we have version numbers like this? Great question! It is because we split off the framework development (ICE schema stuff) from the application development (ERP schema stuff), as we wanted to offer up the ICE framework for use with other products. So, ICE and apps development on the Epicor ERP side are on the same release cadience, but, if the SCR has to do with the framework the version is 3.something–if the SCR has to do with the application code it will have a version of 10.something. If you are using one of those products that isn’t Epicor ERP but uses the ICE framework and it is targeted to 3.something, you have to wait until that product upgrades to that 3.x something ICE framework. I can’t really speak to the particulars / scheduling of how the non-Epicor ERP products plan their releases.
What is the specific SCR you were looking at?
I don’t know how to get an SCR number. This is on a problem PRB0186835. It’s not the only time I’ve seen these release numbers used. It’s just frustrating as a customer because you need the super secret decoder ring to see when it’s going to be fixed. Can you ask them to add the cross reference in the release notes? That would be an improvement.
When a problem is tied to a case, the SCR that is ultimately created from it should bubble up to the case by way of an external case note. Our epiccare operations team has been working on that and is a relatively recent enhancement to the best of my knowledge.
This PRB is tied to SCR 205869, and it is fixed in base 10.2.100–at this time I do not see a request to try to have this retro’d to 10.1.600.x.
@aidacra
Is there a planned end-of-life for lets say 10.2.100.x? How does one know if they should go to 10.2.200.x (cutting edge) instead. We have hopes that 10.2.100 will keep being patched until it hits 10.2.100.37 or so, is that a valid assumption or could it stop receiving patches as soon as 10.2.100.20 ?
An ERP release will enter a sustained support status two years after it becomes GA, which is not the same as EOL. As of today, Epicor has never (to the best of my knowledge) EOLd a product. This isn’t to say that it won’t happen in the future
<cough>
A number of things happen when a release enters sustained support status, but, the most important in my opinion is that no new updates for that release will be provided after two years. Also, calling into support unless it is a system down also ends when a release enters sustaining support. NOTE: new cases can still be submitted via our epiccare portal for a release that is in a sustaining support status.
A slide from one of my sessions at Insights where I discussed sustaining support dates is below. There are exact dates for when 10.1.600+ releases enter sustaining support, but, the point I was trying to relay wasn’t so much the specific date, but, that it occurs two years after GA.
To answer this question:
My advice is to go as current on the release as possible to get as much benefit from the two year period where we will be providing updates for a release. As of today, 10.2.100.x will receive updates for an additional ~18 months where 10.2.200.x will receive updates for an additional ~22 months.
