<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
😄
<div><br>
</div>
<div>I suspect (hope) the majority of customers don’t get involved with ES at all and only care about major/minor/SU upgrades. Those customers just need to know if a license change is involved or how risky the upgrade is (is the version incrementing). </div>
<div><br>
</div>
<div>The fact that our SUs are basically minor releases these days is a whole other debate. <br>
<br>
<div id="AppleMailSignature">-Ryan</div>
<div><br>
On Aug 17, 2018, at 4:41 PM, Anthony Holloway <<a href="mailto:avholloway+cisco-voip@gmail.com">avholloway+cisco-voip@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">I had a good laugh when you posted the link to the careers section of
<a href="http://cisco.com">cisco.com</a>. That was good. ;)
<div><br>
</div>
<div>Thank you for such a detailed post about the versioning. The only thing I really have to say, regards your comment "I would recommend focusing on the version number rather than any labels like ES or SU. The letters are just for convenience."</div>
<div><br>
</div>
<div>So, if you recommend that approach, and the documentation only lists the build, then why even bother with the letters? As it turns out, this "convenience" is an inconvenience, when I have to spend effort converting between them. Would it be possible,
in your opinion to just drop the two formats, and use build numbers only?</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Fri, Aug 17, 2018 at 8:16 AM Ryan Ratliff (rratliff) <<a href="mailto:rratliff@cisco.com">rratliff@cisco.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;line-break:after-white-space">
<blockquote type="cite">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>0) Is there some mapping utility for build to version already out there? <a href="http://cisco.com/" target="_blank">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><br>
</div>
Good question, it would probably be a tech doc that somebody in TAC wrote, if there is one.
<div><br>
</div>
<div>
<blockquote type="cite">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>The part you should care about here is:</div>
<div>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>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><br>
</div>
<div>
<blockquote type="cite">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>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>
</div>
<div>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" target="_blank">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><br>
</div>
<div>
<blockquote type="cite">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>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>
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" target="_blank">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><br>
</div>
<div>If you <b>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" target="_blank">fill out here</a>.</div>
<div><br>
</div>
<div>
<blockquote type="cite">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>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>
</div>
<div>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><br>
</div>
<div>-Ryan </div>
<div><br>
<blockquote type="cite">
<div>On Aug 16, 2018, at 2:36 PM, Anthony Holloway <<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank">avholloway+cisco-voip@gmail.com</a>> wrote:</div>
<br class="m_3791681112135101554Apple-interchange-newline">
<div>
<div dir="ltr">
<div>In the Cisco Live presentation for <a href="https://www.ciscolive.com/global/on-demand-library/?#/session/1509501667293001PMPi" target="_blank">
Best Practices for Migration Previous Versions of CUCM</a>. the following slide is given:<br>
</div>
<div><br>
</div>
<div>
<div><span id="m_3791681112135101554cid:ii_jkwvnoux0"><image.png></span><br>
</div>
</div>
<div><br>
</div>
<div>I'm wondering if the list can help answer the following questions:<br>
</div>
<div>
<div><br>
</div>
<div>0) Is there some mapping utility for build to version already out there? <a href="http://cisco.com/" target="_blank">
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><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>3) What do the postfix digits represent? E.g., The 6 at the end of 11.5.1.10000-6.</div>
<div><br>
</div>
<div>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><br>
</div>
<div>Thanks.</div>
<div></div>
</div>
</div>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</body>
</html>