Consider splitting upgrade guides by version

[lathiat]

Currently, the Anbox docs only seem to render a "latest" version. As such, the upgrade guide shows you how to upgrade the previous version to the current release, and the commands currently have the 1.23 channel specified. This makes it harder to know how to upgrade 1.21 to 1.22 if you haven't yet upgraded.

Frequently customers will end up behind versions, and may need to refer to an upgrade guide for a previous versions. I am not sure how much we expect customers to end up behind on upgrades with Anbox, but with other products this is very common, but I imagine at least it may be more common for people to end up 2 versions behind if they didn't quite finish upgrades before the next release came out.

Some approaches that may work:

• Some products let you view the older releases documentation in full,
• Some products have a separate upgrade page for each version, e.g. 1.20 to 1.21, 1.21 to 1.22, 1.22 to 1.23, etc
• Keeping a single latest "upgrade" page -might- make sense but we need to make sure that the upgrade page makes very clear how to check the current version, if you can skip a version or not, and maintains any release-specific exceptional upgrade notes in a clearly marked section (we have a couple of those in the anbox upgrade docs at the moment)

Our Kubernetes docs used to have a simple list in the documentation tree for each version as noted above, however that seems to have been lost at some point and now instead links to the "per version" upgrade page, although our docs have no other way to switch between versions.. normally if you do this there should be a clear selector on every docs page to jump between versions of the page, and we seem to have lost that. In any case, it is a bit of an example: https://ubuntu.com/kubernetes/docs/1.23/upgrading

[lathiat]

MySQL has a great example of linking between versions, with a version selector on all pages in the top right:
https://dev.mysql.com/doc/refman/9.1/en/upgrading.html

[keirthana]

We understand the issue but the challenge lies in maintaining documentation only for the supported versions. So out of the options you have listed the last one about keeping a single page but having some more information that will help the upgrade process for older versions is the one that makes most sense.

I will discuss this with the team and come up with a Jira ticket to get this fixed.