Update on the Commvault Cloud Release Process - August 2024

I'm not sure if I read it correctly, but I think the information below, taken from the post, should mention December and not July, right? As I understand the yearly LTS release will be based on the innovation release that becomes available in December. 

• Innovation releases will be baselined on July 15 every year and posted for download. From this point, new content will be delivered on the 15th of every month as an “Innovation Update Release.”

As for the LTS release, right now Commvault does occasionally backport new functionality and enhancements to previous release. I assume this will stop, right? Commvault is only going to provide bug fixes? Does this also apply to updates related to the compatibly with supported integrations like hypervisors and storage arrays?

Hi Onno, thanks for the questions.

When we have fully transitioned to the new process, we will create a new LTS release every June and a new Innovation Release baseline every July.  The Innovation Release will be updated monthly with feature content and fixes.  The LTS release will be updated as needed with fixes only.  We will not add new features to LTS releases.

While we have traditionally had a December/June cadence, we are moving to the process outlined in this blog post.  As mentioned above, we will have one more December release (11.38) and will then move to the June/July cadence.

Great question about support for new workload versions.  Support for new versions of workloads will be added to LTS releases unless called out specifically in documentation.  Please refer to documentation for details.

Thanks @Brad Kirby for the clear answers. Once this release schedule becomes active, will it be possible to move from LTS to Innovation or vice-versa? Or do you have to wait for the next "release” to become available before you can make the swap?

Technically “yes.”  Organizations that are on an LTS release may choose to adopt an Innovation Release.  An example of this would be someone who has an immediate need for a specific feature that is delivering in an Innovation Release.  However, the recommended pattern is probably to adopt the next LTS release that includes the desired feature.

@Brad Kirby @Jennifer Kelley I think this information is very important and that it should be pinned on the community landing page. This is currently not the case causing this information to disappear in the pile of posts. Can you fix this?

Hi!

I needed to read the article a few times, but I thiink I understand now. I tried to clarify it for myself using the following image. Do I understand it correctly?

I do also have a few questions, though:

1. A Long-Term-Support release is baselined annually, but at what frequency will updates be released to fix defects? Is that also on a monthly basis? Or does it depend on the amount/severity of defects?
2. Also, how will we be able to identify which stream we are following? Will the innovation releases be called 11.38, 11.40, 11.44, etc. and will the LTS releases be called CPR2024, CPR2025, etc.? That would make it very clear which version/stream a customer is running!
3. If the current Innovation Release is “supported” until the next Innovation Release, and each update also contains new features, then why not just make the Innovation Stream a “Rolling” release? And just call them “2025.06”, “2025.07”, “2025.08”, etc. with every monthly release of updates? That way, it’s easier to understand that each 20xx.06 release will be the baseline of the next LTS release.

Patrick, thanks for the excellent questions.  Let me answer the questions first then speak to the diagram.

Question 1: You can expect LTS maintenance releases to fix defects roughly monthly.  The key is that we will not include feature content with those LTS maintenance releases.

Question 2: Releases will be versioned as follows:

Innovation releases - 11.38, 11.42, 11.46
LTS releases (always divisible by 4) - 11.40 (CPR 2025E), 11.44 (CPR 2026E), 11.48 (CPR 2027E)

Also, we’d like to get your feedback on the CPR numbering mechanism.  Is having CPR 2024 or 2024E helpful, or would it be easier to just use the traditional version numbering (e.g. 11.38, 11.40)?

Question 3: You are correct that Innovation Releases are essentially rolling releases.  The expectation is that you need to upgrade to the latest release to get new functionality or bug fixes.  Your suggestion about versioning is a good one.  The versioning suffix is actually tied into our CI/CD process, so it will take a bit more work to figure out how to simplify things further.

Diagram: Really like this and I may steal it for future training sessions.  It only needs a few tweaks.  As mentioned above, Innovation release will be numbered 11.38, 11.42, 11.46 etc. and will be baselined annually in July (11.38 is an exception as we transition).  LTS releases will be numbered 11.40, 11.44, 11.48 and will be baselined in June (11.36 is an exception as we transition).  So 11.40, 11.44, etc need to move to the LTS steam (11.40 = 2025E) and 11.42, 11.46 etc need to be added to the Innovation stream.

Again, interested in your thoughts on the CPR numbering.  We think having two versioning schemes may be adding to complexity.

Hi @Brad Kirby,

Thanks for your replies.

About the CPR numbering. Just about everyone I speak with, thinks the CPR numbering is confusing. Not only because it’s not evident which is newer (2024 or 2024E). But also because at various locations the traditional numbering is also still used. Most people I speak with (including myself) prefer the traditional numbering method, which is a lot more clear.

That said, if you could keep using the traditional versioning for the Innovation Stream and the CPR numbering for the LTS Stream, that would be great in my opinion! That way everyone can instantly identify if a customer is running the Innovation Stream or the LTS Stream. But I’m not sure that’s feasible.

Alternatively, maybe add the “E” to the regular version numbers for LTS releases. So innovation releases would be 11.38, 11.42, 11.46, etc. and LTS releases would be 11.40e, 11.44e, 11.48e, etc.

I have updated the diagram per your feedback:

I have no problem with you using/updating it, so I have also attached it in LibreOffice Draw format to this post, so you can easily edit it to your liking.

When this new version numbering was introduced, I was expecting the old numbering to disappear. That didn't happen, so that is for sure causing confusion. 

I think veterans who have been using the product for a long time generally speaking will not be in favor of making a change. People in general dislike changes who are enforced, right ;-) The current numbering starts with 11 which is a reference to version 11 that was introduced years ago. This number is therefore not relevant anymore and should imho be removed. This leaves the build number, or whatever you want to call it, which is just a number that with the current version is already on 36. Are we moving to 100?? I think the numbering makes no sense anymore and for customers who are new to the product it is also an odd way of numbering. So I think the CPR naming makes way more sense!

Getting used to a year number for the innovation release and the adding of E(xtended) to mark the LTS release is something you get used to quickly. On the other hand why not name it 2024LTS or 2024-lts. All in all I think the best way forward is to make the switch completely and remove all references to the old numbering and stop using it internally as well which includes support and engineering.