<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="">
<div class="">0) Is there some mapping utility for build to version already out there? <a href="http://cisco.com/" class="">cisco.com</a> downloads in not ideal, because not always can you find all historical versions, and rarely if ever can you find ESes,</div>
</div>
</div>
</blockquote>
</blockquote>
<div class=""><br class="">
</div>
Good question, it would probably be a tech doc that somebody in TAC wrote, if there is one.
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="">
<div class="">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?</div>
</div>
</div>
</blockquote>
</blockquote>
<div class=""><br class="">
</div>
<div class="">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. </div>
<div class=""><br class="">
</div>
<div class="">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. </div>
<div class=""><br class="">
</div>
<div class="">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. </div>
<div class=""><br class="">
</div>
<div class="">The part you should care about here is:</div>
<div class="">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.</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="">
<div class="">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</div>
</div>
</div>
</blockquote>
</blockquote>
<br class="">
</div>
<div class="">Typically yes, it’s not often that a bug fix is so severe that it warrants quickly incrementing a version that was posted to
<a href="http://cisco.com" class="">cisco.com</a> and when it happens you the get the letter added to indicate that it’s something different, but newer than the older one. </div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="">
<div class="">3) What do the postfix digits represent? E.g., The 6 at the end of 11.5.1.10000-6.</div>
</div>
</div>
</blockquote>
</blockquote>
<br class="">
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
<a href="http://cisco.com" class="">cisco.com</a> (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. </div>
<div class=""><br class="">
</div>
<div class="">If you <b class="">really must</b> know the minutia of how the versions work, there’s a form you can <a href="https://www.cisco.com/c/en/us/about/careers.html" class="">fill out here</a>.</div>
<div class=""><br class="">
</div>
<div class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<div dir="ltr" class="">
<div class="">
<div class="">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?</div>
</div>
</div>
</blockquote>
</blockquote>
<br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">-Ryan </div>
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Aug 16, 2018, at 2:36 PM, Anthony Holloway <<a href="mailto:avholloway+cisco-voip@gmail.com" class="">avholloway+cisco-voip@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">In the Cisco Live presentation for <a href="https://www.ciscolive.com/global/on-demand-library/?#/session/1509501667293001PMPi" class="">
Best Practices for Migration Previous Versions of CUCM</a>. the following slide is given:<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div class=""><span id="cid:ii_jkwvnoux0"><image.png></span><br class="">
</div>
</div>
<div class=""><br class="">
</div>
<div class="">I'm wondering if the list can help answer the following questions:<br class="">
</div>
<div class="">
<div class=""><br class="">
</div>
<div class="">0) Is there some mapping utility for build to version already out there?
<a href="http://cisco.com/" class="">cisco.com</a> downloads in not ideal, because not always can you find all historical versions, and rarely if ever can you find ESes,</div>
<div class=""><br class="">
</div>
<div class="">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?</div>
<div class=""><br class="">
</div>
<div class="">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</div>
<div class=""><br class="">
</div>
<div class="">3) What do the postfix digits represent? E.g., The 6 at the end of 11.5.1.10000-6.</div>
<div class=""><br class="">
</div>
<div class="">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?</div>
<div class=""><br class="">
</div>
<div class="">Thanks.</div>
<div class=""></div>
</div>
</div>
_______________________________________________<br class="">
cisco-voip mailing list<br class="">
<a href="mailto:cisco-voip@puck.nether.net" class="">cisco-voip@puck.nether.net</a><br class="">
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" class="">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>