Cisco Customer Success - Video

ACI Release Lifecycle and 6.2.x timeline

Playback confirmation!

Do you want to resume playing from last left location?

Chapter 1 Thumbnail
00:00
Overview of the 6.0 release cycle
Chapter 2 Thumbnail
00:40
Extended 6.1 lifecycle: longer maintenance and security coverage
Chapter 3 Thumbnail
02:21
6.2 train roadmap and overlapping release trains
Chapter 4 Thumbnail
03:31
Feature release cadence and strategic focus
Chapter 5 Thumbnail
04:51
Maintenance strategy and recommended stable releases

Transcript

Oh I just want to start with a quick refresher on our current software release cycle, which we started implementing in the six zero release train.00:00So, that cycle runs four years, begins with a twelve month development phase for new features and capabilities. In general, the idea was to start with a twelve month development phase that produces three feature releases similar to what we've done with NXOS now for a number of years. And then after that development phase, we enter a 15 month maintenance cycle, providing bug.00:16Fixes patches to harden the release code and make it more stable.00:36And then the cycle moves into 15 months of extended support primarily for piece heart fixes before transitioning to a final six month period of tax support before the release train goes into life. So that was new with six zero, but starting with the six one train, we introduced a more extended life cycle for the six one train for our eight.00:40CI releases. So on this slide you can see how the new cycle is four and a half years total as opposed to that previous four. So with the new one, we'll still have a feature or a twelve month development cycle with three feature releases, but the significant change or one significant change is the extension of our maintenance phase, which now provides 18 months of bug fixes.01:00Hardening and and maintenance releases. And we've also boosted our face of P cert coverage offering now 24 months of vulnerability fixes, so you get an additional nine months as compared with the previous life cycle.01:20The main point here is or the main idea behind extending the release cycle is to enable customers to spend more time on our stable maintenance releases. The goal is to provide them with a longer window of operational stability and and basically give them more time to confidently confidently run an ACI release train for a longer period of time before they need to.01:31Plan their next major upgrade. And yeah, as you'll probably know, we have a lot of customers who are also staying past LDOS or last day of support on all the releases like five two or five three and so another idea with this extended.01:51Life cycle, as well as some of the work we've been doing in ACI software directly to make upgrades relatively faster and more centralized. Another one of our objectives is to make it easier for our customers who are behind on the 5253 to actually catch up again on some of our latest releases.02:05And the last thing I want to show here is what the six two train is gonna look like, which will be so six one is where we implemented this new release cycle. Six two will follow it as well. So moving toward the right, you can also see our expectation of when we plan to ship the remaining feature and maintenance releases in the rest of the six two train. One.02:21One more thing I should call out and I should have added a slide on this is that at the same time there's kind of overlap or stacking of our different release trains. So at the same time that we start the.02:40Development phase for a new one like six two that coincides with the time that the previous train goes into its maintenance phase, so at the same time that we released 621 and the six one train is moving from the development phase into the maintenance cycle. So 615 just got released.02:51And our expectation is that our hope is that in the next six to eight weeks after giving that release a little bit of time to, to soak, that can become our target gold star release for the six one train. In terms of the feature releases yes, we have three per year typically. So like with six two, e.g., we'll have this 1621 coming.03:06In December and then March and then November before it goes into the maintenance phase, and that's.03:26Feature releases tend to be a mix of two things. So one we're trying to address escalations that we get from customers or certain feature gaps that they see with with the product itself with ACI. But then another big reason we do these new releases is because we wanna help position ACI according with our, our, our business unit strategy. So we want to introduce some.03:31For new security features or.03:50Provide enhancements to help position ACI for front end, customers who want to use it for front end AI networks e.g. or work on our integrations or cross domain integrations with platforms like Splunk or thousandeyes and others. So it's a mix of those two things. We typically have customers reaching out saying, hey, we need this gap addressed or this new feature or it's us.03:53We're Actively trying to align ACI even closer with our strategy.04:13But then obviously we need to provide the feature releases, I would say a very small percentage of our customers actually go to. They're either the ones who are, they tend to be ones who are looking for something specific in terms of a feature that's coming in that release. A lot prefer to wait until the code has had more time. We've been able to figure out what bugs exist.04:17Provide patches, so that's then the release, the reason for the big maintenance cycle of the the remaining three and a half years in the train is to actually give them a long amount of time to say, hey, you know what, we're done adding new features to this release.04:36We are not telling every customer to move to every maintenance release. They can choose one maintenance release that they can go to and, and, and stay there for about two years. Now, e.g., if you want to take.four or.five customer chooses, he can go ahead or they can go ahead and qualify and stay on that branch.04:51And we are not telling move to.six when.six is available, move to.seven and.seven is available. We are giving it so that customers who are looking for that fix can go one and there are fixes which come in. So if there is a CV or a piece that comes in, we can't let customers wait for a year, right? And.05:12Fact, the reason why we are bringing in these is because of the P cert fixes that come in and customers want a release with that fix if there's a security right? And again, we we Every customer doesn't have to go to every maintenance release, they can pick and choose.05:32And then we can go the the the release is available right and if there is a need, they can move. If they really don't see a need to go to a particular bug fix, right? If it is there in, let's say they are in.four and there is a bug fix which comes out in.five.05:51If they don't see it, they don't have to go, right? So that's the. Yeah, yeah, we are, we are because again turnaround time is much faster if anybody needs any fixes that come in, right? We don't want them to wait for a year.06:10Because that's another huge you know ask from customers, like you give me one release now and if I have a bug fixed, I have to wait for a year to get a bug fixed correct so and and also on the P search thing, we'll we'll have to.06:31You know, address them as early as possible, right? So that's one of the reasons. I guess the only other thing I would add is that really most of our I guess what the release we tend to position the most I would say is the 1st maintenance release in a train, like 615 e.g. in the six one train.06:49And then a year later, it'll be 624 the 1st maintenance release in the six two train because that's where we can say, ok, NO more features, the code's relatively stable, we have a good amount of confidence in the stability of this code. We can now recommend it to you as a, the version to go to in this train. Having the three releases over the course of the year is more a way for us to like Sharney was saying, address.07:07Specific customer requests and then if those customers want, they can go immediately when the code comes out. But really it's about once a year once we go into the maintenance phase of a certain release train that we actually say, ok, we have a pretty.07:27Complete new train, it includes these features that we introduced and the code's relatively stable, we have confidence to tell you to go say deploy that code like 615 e.g.. Beyond that, the additional maintenance releases are much more way to just continue addressing bugs that come up and we don't have to make a huge announcement around them, I guess, but.07:39Yeah, point taken that you don't want to be overwhelming while at the same time you do wanna be addressing some of the gaps or some of the enhancements that customers are requesting.07:58

About this Video

Author : Cisco Customer Success

Uploaded : September 15, 2026

Data CenterApplication Centric Infrastructure
AI summary icon

AI summary

Explore the updated software release lifecycle for Cisco Application Centric Infrastructure (ACI). The recording covers the four and a half year 6.1 and 6.2 trains: a twelve month development phase with three feature releases, an extended eighteen month maintenance window, and twenty four months of PSIRT coverage, with guidance on security enhancements, stable maintenance releases, and faster, centralized upgrades.

  • Understand how the extended lifecycle increases operational stability.
  • Learn to select a first maintenance release and leverage PSIRT fixes.
  • Plan upgrades using train stacking and cadence to reduce risk.