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.
