Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Empty Tag will Serve Latest Version (Highest Semver) #175

Open
cahillsf opened this issue Aug 29, 2023 · 2 comments · May be fixed by #176
Open

[Feature Request] Empty Tag will Serve Latest Version (Highest Semver) #175

cahillsf opened this issue Aug 29, 2023 · 2 comments · May be fixed by #176

Comments

@cahillsf
Copy link

cahillsf commented Aug 29, 2023

The current behavior of the docs site will serve the tag with the most recent time attribute (src code) if no tag is provided in the URL params. My current understanding is that the time attribute is populated based on the latest push to the tag when the tag is indexed. It seems that once the tag has been initially indexed, the time will not be updated as the app will only reindex tags it has not seen before (src).

This means that repo owners do not necessarily control the ordering of the tags and the site will not always serve the latest version as indicated by semver. For example, currently the CAPI repo is serving v1.4.5 when no tag is provided in the URL params, despite the fact that v1.5.0 is the true latest.

This is a request to update the logic when no tag is provided in the URL params to prefer the latest tag by semver (if the repo's tags adhere to semver), rather than the time attribute from the tags relation in the doc db.

@furkatgofurov7
Copy link

/cc @hasheddan

@furkatgofurov7
Copy link

@hasheddan hey 👋🏼 Any chance this FR is considered and moved further, so we can take benefit of it while consuming this project? Thanks in advance!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants