Vault Upgrade Frequency

We are looking to find the the recommended best practice for upgrading Vault in regards to upgrade frequency. Official documentation states that:

Vault upgrades are designed such that large jumps (ie 1.3.10 → 1.7.x) are supported.

Question 1: Is it recommended, for example, to stay at v1.10.4 and wait until v1.12 is released to go directly to the latest version of v1.11 (skipping all minor upgrades in between)?

Question 2: Is it possible/recommended to wait longer before upgrading (ie. jumping directly to two or three major versions)?

There’s a lot of complexity in this question, so I don’t think a simple yes or no answer is enough.

Let me try and break it down a bit:

Q: You are currently running 1.10.4, and a future 1.10.5 is released. Should you upgrade?

A: You should read the changelog and make a value judgement whether the fixes are important enough to you, to justify the deployment effort.

Q: You are currently running 1.10.4. Several additional 1.10.x releases have happened. Several 1.11.x releases have also happened. Can you upgrade directly from 1.10.4 (not the latest 1.10.x) to 1.11.(latest)?

A: Yes, this is absolutely fine, unless there is some (very rare!) special announcement to the contrary in the upgrade notes.

Q: When should I upgrade from 1.10.x to 1.11.x?

A: Initial releases of a new release series can be a bit problematic. 1.10.x is an excellent example of this - I think it was 1.10.3 before the series had overcome initial “teething troubles”. Unless you really want to live on the bleeding edge, it is wise to give a new release series a few months and a few point releases before looking to push it to a production scenario, unless you’re desperate for new features.

Anecdotally, I can report successful upgrades from 1.1 → 1.5 → 1.9. even says:

Vault upgrades are designed such that large jumps (ie 1.3.10 → 1.7.x) are supported.

The important thing to bear in mind, is that if you’re more than 2 release series behind, you’re no longer going to have new patch releases available for security or major bugfixes - meaning that allowing a production Vault deployment to become more out of date than that, should only ever be part of a temporary short-term strategy to reduce work of rolling out new versions, with a plan to catch up later.