cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
479
Views
1
Helpful
6
Replies

Difference of release trains: Cupertino vs Dublin vs Bengaluru

Coco Liu
Level 1
Level 1

Dear all:

Could anyone please help to explain the difference between release trains, this is what I found in chatgpt.

I posted it here to double check whether it is correct or not.

1.Cupertino Release Train:
Focus: Mainstream, general-purpose, and highly stable.
2Dublin Release Train:
Focus: Newer features and innovations.
Stability: Less stable compared to Cupertino
3.Bengaluru Release Train:
Focus: Evolutionary step beyond Dublin, continuing with new feature developments.
Stability: Similar to Dublin in terms of introducing new features but possibly with a higher degree of maturity as it builds upon the features introduced in earlier Dublin releases.

 

Thanks

6 Replies 6

@Coco Liu 

 This is too superficial. Take the Release notes for each one and go to "Whats New in Cisco IOS XE Dublin" do the same for the  others. 

. There Cisco explain what have changed. You can summarize it.  

Joseph W. Doherty
Hall of Fame
Hall of Fame

There are just code names for different IOS trains, when they were being developed (when you want to keep "new" features secret).

Much or more is probably better inferred by actual IOS version numbers and other Cisco documentation.

IOSXE: 17.13..14 (14 being the latest)

Dublin: 17.10..12

Cupertino: 17.7..9

Bengaluru: 17.4..6

For individual releases, you would want to see their letter classifications, usually ED (Software releases that provide new features and new platform support in addition to bug fixes. Cisco IOS CTED, STED, SMED, and XED are variations of ED software releases.) or MD (A Cisco software release that provides bug fix support and ongoing software maintenance.), and/or read the release notes, take special note to what hardware and software features were changed per release.

Concerning maturity, you would look for releases tagged with a star and/or (sometimes) separately documented release recommendations.

Leo Laohoo
Hall of Fame
Hall of Fame

Names of mountains mean nothing but sow confusion. 

Different trains offer different features and introduce a plethora of bugs.  Adding names of mountains as a prefix or suffix is just a way of making each firmware release "smell better".  

Ramblin Tech
Spotlight
Spotlight

Software release-throttle and hardware-platform projects get codenames early in their in development process because the actual release numbers or product names/models get assigned by Marketing much later. During the dev process the projects have to be referred internally to by some label, so their product managers come up with codenames that do not give away any info about their true nature. Sometimes the codenames are mundane (eg, geographical references), sometimes they are geeky (eg, scientific, sci-fi, or fantasy references), and sometimes they are just for fun (eg, “BFR”, “HFR”).

Disclaimer: I am long in CSCO

Joseph W. Doherty
Hall of Fame
Hall of Fame

Rereading OP, always take anything from a current AI, like your ChatGPT reference, with a very large grain of salt.  Those AIs still are limited to the old computer saying GIGO (garbage in, garbage out).

For example:

Dublin Release Train:
Focus: Newer features and innovations.
Stability: Less stable compared to Cupertino

Well, yea, as it's both a later release, and its releases are ED status.

Bengaluru Release Train:
Focus: Evolutionary step beyond Dublin, continuing with new feature developments.
Stability: Similar to Dublin in terms of introducing new features but possibly with a higher degree of maturity as it builds upon the features introduced in earlier Dublin releases.

As Dublin has later release numbers than Bengaluru, interesting ChatGPT notes it builds on an earlier Dublin release.  Well, if ChatGPT somehow knows the internal software development tree, within Cisco, guess that might be true, but not apparent from how the release was released.

For some side commentary . . .

Leo's comments, I believe, equate to something similar to pigs and lipstick, and I agree a "fancy" name guarantees nothing.  (Of course if such a release was noted as being "new and improved" or better yet, perhaps, lemon freshened, well then we would know it must be good - laugh.)

No doubt Jim is correct, projects are named, and code named, if you're trying to keep what they do not inferable by the project name during development.  What I don't recall, decades ago, was Cisco sharing these names with product release.  Possibly, this was also done as some later marketing ploy, i.e. a cool name means it's cool software (although still hard to beat lemon freshened).  (Jumping/skipping version numbers, also means a huge improvement in software, hmm, like going from version 12.x to 15.x or version 8 to version 10, but we won't mention vendors - again, but lemon freshened, is even better.  [BTW, marketing is important, just consider P.T. Barnum's most famous quotation.])

Jim describes, names are assigned before release numbers.  No doubt true, but it's hard to imagine there's not some larger overall implementation plan that targets where a certain project will fall into final deployment, even very early on.  Certainly, early on, no one might be able to say the project will be the .# release.  But, it's probably planned within a few release digits.  I.e. we're targeting .5, but it might be .4 or .6.

Interestingly, Cisco, some years back, changed their software release structure.  Decades ago, there was a mainline train, that was feature frozen with .1.  All later releases were just bug fixes.  By about .10, such a software train became very stable.  New features, software and/or hardware were incorporated into parallel software release trains (which were also frozen, I recall, except for bug fixes in the main train) or incorporated into the "T" release train, which would become the new version release.  The latter, would basically include most newer features, software or hardware.

I imagine, the older structure was a PIA for Cisco to manage.  However, if you understood it, from a customer perspective, if meant you could choose maximum stability (using a mainline train), or chose some risk, for some new feature (e.g. new HW module) using a parallel train, or chose maximum risk if you want multiple new features, by using the "T" train.

The latest development model, appears to much mimic the early "T" train, i.e. where Cisco incorporates new features and bug fixes into the same train.  Great for getting the latest features, but possibly not as great for stability (probably this much accounts for Leo's view, not incorrectly, IMO, that Cisco software was "better" years ago, but you had to well understand their earlier release train model to obtain such stability, and the trade offs in using just main train software). 

Lastly, although in the above, I poke fun at marketing, and infer Cisco's later development model may have decreased (user selection) stability of their software, having spent about 3 decades of my career as a software developer, there's more to software development issues, then I touch upon above.  Anytime you compare "now" with the "good" old days, if you dig deeper, you often find the "old days" were not necessarily "good", and often there are many reasons for what seems to be "worst" now.  For example, current Cisco software often has many, many more features they Cisco software of decades ago.  Unfortunately often many new features, which can be very "good", usually increase software complexity, which often leads to reduction is stability.

Cisco, and other vendors, also need to contend with the infamous "Iron Triangle", i.e. fast, good, cheap.

Coco Liu
Level 1
Level 1

Thanks for the posting. I have checked with TAC, and here is what they replied:

At a high level, there are two types of releases: Standard Support (Early Deployment or ED) and Extended Support (Maintenance Deployment or MD).  New features are typically introduced in ED releases, while MD throttles focus on longevity and stability with numerous bug fixes over a longer period of time.  MD throttles are “every third version” in a train of code (17.3, 17.6, 17.9, 17.12, etc.), while EDs are typically the other, intermediate versions (17.1, 17.2, 17.4, 17.5, etc.).  The Train Identifiers (Bengaluru, Cupertino, Dublin, etc.) are fairly generic groupings of code versions.  Like 17.7, 17.8, and 17.9 are all under the Cupertino identifier.  Typically, when Cisco Team(TAC, BU, Developers) reference code versions, they  use the specific version number (like 17.6.8) rather than the Train Identifier.

 

In terms of evolution, Bengaluru (17.4-17.6) came first, then Cupertino (17.7-17.9), followed by Dublin (17.10-17.12).  So Dublin would have the latest and greatest features integrated.  In addition to the Release Notes, you can also leverage the Cisco Feature Navigator tool for comparisons:

https://cfnng.cisco.com/

 

This tool isn’t comprehensive in terms of including all possible release, but you can use it to get an idea of major differences in features between releases.  For example:

 

CocoLiu_0-1730488713322.png

 

Review Cisco Networking for a $25 gift card