[cisco-voip] CUCM Build to Version Conversion

[Ryan Ratliff (rratliff)]

0) Is there some mapping utility for build to version already out there?  cisco.com<http://cisco.com/> downloads in not ideal, because not always can you find all historical versions, and rarely if ever can you find ESes,

Good question, it would probably be a tech doc that somebody in TAC wrote, if there is one.

1) For an ES, is it always tied to an SU?  Example: 11.5.1.11101-n would be 11.5(1)SU1ES1, correct? And 11.5.1.11901-n would be 11.5(1)SU1a, right?  But then, how would 11.5(1)SU1aES1 look, as a build version?

There is a relationship between ES and SU but it’s not the way you are describing. ES images are built on a fixed schedule, for every version that is still being maintained. The code changes that go into them are restricted to only bug fixes that customers hit AND have specifically requested to go into an ES. I would recommend focusing on the version number rather than any labels like ES or SU. The letters are just for convenience.

Each SU starts as an ES (forked from that branch, in sw dev terms). When the SU branch is pulled it’s “Y” number (from the slide) is incremented. At that point the SU branch is updated separately from the ES, though it’s likely some bug fixes go into both. Any features or other work that is intended to go into the SU will also be committed to the SU, but not to the ES.

After the SU is released the ES branch will get merged with the SU branch. At this time the “Y” number in the ES version will be incremented to match the SU.

The part you should care about here is:
1)  If you get an ES from TAC that has the “Y” number higher than your current version you will automatically pick up any features that were in the SU(s), so be aware.
2)  If you upgrade to an SU and hit a bug that is fixed in an ES, you must wait until an ES is available with the same “Y” number or you will be downgrading. Only early adopters of SUs may hit this situation because the ES versions typically merge with the SUs within a month of release.

2) When the patch on the minor or SU comes out, does that usually mean the previous patch version was differed?  E.g., 11.5(1a) differs 11.5(1) or 11.5(1)SU2a differs 11.5(1)SU2

Typically yes, it’s not often that a bug fix is so severe that it warrants quickly incrementing a version that was posted to cisco.com<http://cisco.com> and when it happens you the get the letter added to indicate that it’s something different, but newer than the older one.

3) What do the postfix digits represent?  E.g., The 6 at the end of 11.5.1.10000-6.

Without going into too much detail the last number increments with each build of the release. The most important thing about this last number is that if for whatever reason a customer is running some version that isn’t quite the version on cisco.com<http://cisco.com> (11.5.1.10000-4 for example) then they must get to a public release immediately. At the point we start numbering a build for public release the only reasons we increment the build are for bugs that we absolutely will not include in code that goes out.

If you really must know the minutia of how the versions work, there’s a form you can fill out here<https://www.cisco.com/c/en/us/about/careers.html>.

4) How do we know what version is considered a long life release?  I can guess that all .0 releases are NOT long life, but then in the case of 9.0, 9.1(1) and 9.1(2), we have: short, short, long.  And in the case of 8.0, 8.5, 8.6, we have: short, short, long.  Therefore, it's not accurate to say, .5 releases are long life, because in 9.x there wasn't one, and in 8.x it was actually 8.6.  Therefore, you likely cannot derive it from the number alone, so is it published somewhere?

It is my understanding that the .5 releases are long life. The concept of short vs long life releases didn’t exist when 8.x was released so don’t try to apply it back that far.

-Ryan

On Aug 16, 2018, at 2:36 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:

In the Cisco Live presentation for Best Practices for Migration Previous Versions of CUCM<https://www.ciscolive.com/global/on-demand-library/?#/session/1509501667293001PMPi>. the following slide is given:

<image.png>

I'm wondering if the list can help answer the following questions:

0) Is there some mapping utility for build to version already out there?  cisco.com<http://cisco.com/> downloads in not ideal, because not always can you find all historical versions, and rarely if ever can you find ESes,

1) For an ES, is it always tied to an SU?  Example: 11.5.1.11101-n would be 11.5(1)SU1ES1, correct? And 11.5.1.11901-n would be 11.5(1)SU1a, right?  But then, how would 11.5(1)SU1aES1 look, as a build version?

2) When the patch on the minor or SU comes out, does that usually mean the previous patch version was differed?  E.g., 11.5(1a) differs 11.5(1) or 11.5(1)SU2a differs 11.5(1)SU2

3) What do the postfix digits represent?  E.g., The 6 at the end of 11.5.1.10000-6.

4) How do we know what version is considered a long life release?  I can guess that all .0 releases are NOT long life, but then in the case of 9.0, 9.1(1) and 9.1(2), we have: short, short, long.  And in the case of 8.0, 8.5, 8.6, we have: short, short, long.  Therefore, it's not accurate to say, .5 releases are long life, because in 9.x there wasn't one, and in 8.x it was actually 8.6.  Therefore, you likely cannot derive it from the number alone, so is it published somewhere?

Thanks.
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180817/97c7f0c6/attachment.html>