search

ewjoachim / sphinx-github-changelog

Build a sphinx changelog from GitHub Releases
https://sphinx-github-changelog.readthedocs.io
MIT License
26 stars 4 forks source link

FEATURE REQUEST: ignore pre-releases #121

Open jgunstone opened 7 months ago

jgunstone commented 7 months ago

hi there, I share the release history with users / consumers of apps using sphinx-github-changelog. Ideally they wouldn't be able pre-realeases... is this possible?

many thanks John

ewjoachim commented 7 months ago

It should certainly be ! I think it would make sense if it was configurable, but I can be convinced otherwise.

Would you be interested in making a PR?

ewjoachim commented 6 months ago

So, I wonder if pre-releases should never be considered, or if it should be a choice, and if it's a choice, should that be a directive option or a conf.py option?

Any opinion?

jsstevenson commented 3 months ago

very late to this conversation but prereleases definitely should be considered sometimes. this feels like something that would be a directive.

ewjoachim commented 3 months ago

this feels like something that would be a directive.

We could make it a directive, but I believe it's likely some people actually need to enable it in some builds and disable it in other builds (e.g. depending on the branch), so it's likely that enabling it in conf.py will make it easy to to set via a build-defined env var.

@jsstevenson are you interested in contributing this ?

jsstevenson commented 3 months ago

@jsstevenson are you interested in contributing this ?

Personally, I am more than happy with the way things are now (pre-releases included by default) -- most of our open source development is pre-release. Just wanted to voice my opinion (overall very appreciative of the package btw).

ewjoachim commented 3 months ago

Ah sorry I meant: @jgunstone : interested in contributing this ?

jgunstone commented 3 months ago

hi @ewjoachim - apologies for my silence here - I think this package is great - but in the end we've opted to manually produce the release notes and then just link back to them in the GH release. Main issues were: managing the GH authentification added complexity, the structure of our repos isn't that tidy so client facing release notes typically pick up changes across more than one repo. As such, I don't think I'm gonna be able to put any time to this. Thanks for your help. I'll leave the issue open, but of course feel free to close it if you're not planning to pursue this further. Thanks!