[cisco-voip] CUCM Build to Version Conversion

Anthony Holloway avholloway+cisco-voip at gmail.com
Fri Aug 17 16:41:12 EDT 2018


I had a good laugh when you posted the link to the careers section of
cisco.com.  That was good.  ;)

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."

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?

On Fri, Aug 17, 2018 at 8:16 AM Ryan Ratliff (rratliff) <rratliff at cisco.com>
wrote:

> 0) Is there some mapping utility for build to version already out there?
> 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 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 (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> 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 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
> 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/43c99016/attachment.html>


More information about the cisco-voip mailing list