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

Handling version numbers and ref sorting #50

Open
djhoese opened this issue Sep 23, 2020 · 2 comments
Open

Handling version numbers and ref sorting #50

djhoese opened this issue Sep 23, 2020 · 2 comments
Labels
type:task An atomic feature / thing to be implemented

Comments

@djhoese
Copy link

djhoese commented Sep 23, 2020

Currently the references are sorted based on remote (it is a remote or local reference), but this doesn't take into consideration the date or refname of the references. Where this is a problem is with tags that are semantic versions. For example, in my project I have tags v0.7.0 and v0.7.1. By the default sorting of sorted this will process v0.7.0 first. If I identify this version as 0.7 then that means the 0.7 version of my documentation will be based on the older tag which I assume is undesirable in most cases. I think a simple fix might be (reverse the sort and negate the is_remote):

    if config.smv_prefer_remote_refs:
        gitrefs = sorted(gitrefs, key=lambda x: (x.is_remote, x.refname, *x), reverse=True)
    else:
        gitrefs = sorted(gitrefs, key=lambda x: (not x.is_remote, x.refname, *x), reverse=True)
@tfoote
Copy link
Contributor

tfoote commented Sep 24, 2020

We have a use case where we're using codenames and not specific versions. There's currently a debate about whether to sort it forwards or reverse alphabetically. It would be great if there was a way to control or override the sort generally depending on the preference of the developer/documentation writer. Just changing the default will make it work better for some cases and worse for others.

@djhoese
Copy link
Author

djhoese commented Sep 24, 2020

Yeah understood. In the case of code names though, each code name is resolved to a separate output version/directory, right? In the case above my 0.7.x versions need only the newest one to be created. Currently this doesn't work.

Of course having options for all of this would be nice.

@BurningEnlightenment BurningEnlightenment added the type:task An atomic feature / thing to be implemented label Oct 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:task An atomic feature / thing to be implemented
Projects
Status: Ready
Development

No branches or pull requests

3 participants