search

sphinx-contrib / sphinxcontrib-versioning

Sphinx extension that allows building versioned docs for self-hosting.
https://sphinxcontrib-versioning.readthedocs.io/en/latest/
MIT License
127 stars 80 forks source link

Separate handling of release candidates #34

Open bmcfee opened 7 years ago

bmcfee commented 7 years ago

As I understand it, we basically have two options for the "default" root version of the docs: master (or some other branch of choice) or the latest (or highest by semver ordering) tag.

This logic doesn't quite work when the latest tag is a pre-release and master is development. For example, I have a project where master is the development version, tag 0.4.3 is the latest stable release, and 0.5.0rc0 is the most recent tag. (I think this is not an uncommon scenario.) In this case, it would be nice to have an option to build docs for release candidates/pre-releases, but keep the default as the highest non-rc tag.

Does this seem reasonable, and would it be difficult to pull off?

(Unrelated: thanks for building this package. It's awesome!)

Robpol86 commented 7 years ago

Thanks for the unrelated note :)

This makes sense, I can't believe I didn't realize it sooner since we do something similar at work. It's been a while since I worked on this so I'm not sure how long it'll take me to write a (hopefully) modular solution (maybe let users override the logic by specifying a function in conf.py or something).

It'll probably take a weekend of work by my estimates. I'll try to work on it in a couple of weeks.