"Version" based on the highest (version) tag

[buhtz]

What's the problem this feature will solve?

Using RTD with a repository following the OneFlow branching model where there is only one branch. The latest commit in that branch reflects the latest development state (possible unstable) and the highest v* tag is the latest stable version.

Describe the solution you'd like

The "stable" version on RTD should not follow a specific branch or a specific tag. But it should look for the highest tag based on a pattern like v*.
For example you can get the highest tag (without a pattern ) on bash via git with git -C $REP_URL describe --tag --abbrev=0

Additional context

Keep in mind this is useful for repos having only one branch but having the need of the two (usual) docu version stable and latest/unstable.

[stsewd]

Hi, we already do this automatically, if you build your docs, you'll get two versions, latest and stable, latest points to the main/master branch (can be changed to point to any other branch or tag), and stable points to the mayor version tag sorted by SemVer.

[buhtz]

and stable points to the mayor version tag sorted by SemVer.

Never noticed that. Nice to know. It is totally unclear from using the UI.
I would say there is room for improvement.

The current UI suggest that everything is build based on branches or specific tags. Nowhere tag-patters or SemVer are mentioned.

[stsewd]

This is described at https://docs.readthedocs.io/en/stable/versions.html.

@agjohnson thoughts about having some kind of mention of this in the UI?

[agjohnson]

I always prefer to solve UX/UI issues though UI changes, rather than explain our UX with prose content. There's a limit to what users will spend time reading and extra prose content usually clutters the UI more than anything.

To address the UX issue of us not being transparent about these aliases, I still really like the idea of surfacing these as true/mock automation rules. This would help explain these concepts visually and would give us something concrete to link to in the UI even.

We can also be clearer that latest and stable versions are pointers/aliases -- the new dashboard takes a stab at this by labeling the branch/version and the hover popup on the label helps describe things more.

[buhtz]

I always prefer to solve UX/UI issues though UI changes, rather than explain our UX with prose content. There's a limit to what users will spend time reading and extra prose content usually clutters the UI more than anything.

I agree here.

We can also be clearer that latest and stable versions are pointers/aliases -- the new dashboard takes a stab at this by labeling the branch/version and the hover popup on the label helps describe things more.

For some new users it might also not be clear that "stable" and "latest" is something different from a branch. Maybe name that more precise "Version "stable"" and "Version "latest"". And behind it a simple text "points to" or "linked to" something like "branch main" or "highest tag pattern v*.." or "Highest version tag based on pattern v*..".

[humitos]

I always prefer to solve UX/UI issues though UI changes, rather than explain our UX with prose content.

We will be eventually able to use the same algorithms we are going to use to sort the versions in the flyout (as @stsewd suggested in #11069), where the pattern is also customizable.