Hi Colleen, unfortunately there isn’t a good way to handle this today. Say you have v1, v2, and v3 versions of documentation available at:
The latest version (v3) of the documentation will always be located at the root (devdocs.example.com), while the non-latest versions have the version in the URL (devdocs.example.com/1.0, devdocs.example.com/2.0). Once you add a v4, it will start to be served from the root, while v3 will be served from devdocs.example.com/3.0. Since the latest version isn’t added to the URL, there isn’t a way to pin the URL to a specific latest version.
What you could try instead is not versioning the project at all, and, instead, managing the different API versions with separate files. For example, having the files
myspec.v1.3.oas2 that provide the different versions of the API. Then in your hub you could have specific pages for v1.1, v1.2, etc where the URL path would be customizable, which would allow you to have a devdocs.example.com/v1.1, devdocs.example.com/v1.2, and so on.
It would probably mean a little bit more work from an organizational perspective, but it would allow you to bypass some of the shortcomings that come with the versioning system today.