You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've just ported the documentation for on of my older projects to Sphinx and, since I really, really like releases, I was hoping to port that project's change log to releases too.
This project didn't follow semantic versioning until very recently, so a lot of features went in to 1.2.x releases.
I see there's a releases_unstable_prehistory option which seems almost designed for this use case, but (as documented) this doesn't affect 1.0+ releases.
What are your thoughts on this?
Thanks!
The text was updated successfully, but these errors were encountered:
+1 on the overall idea; I think it'd be easy enough to change the hardcoded '1.0' to 'whatever the user wants'. It's possible that 'easy' means 'has to be a major version number', and that terminating 'prehistory' on a minor release (like 1.3) is harder...would have to see.
I don't have time to work on this myself right now but I'd definitely discuss a PR :)
I'd definitely like this. I just ran into the need for this while fixing up twine's changelog (pypa/twine#299) and would appreciate simply being able to turn on this toggle indefinitely, with no particular version number deadline for switching to semver.
Hi there!
I've just ported the documentation for on of my older projects to Sphinx and, since I really, really like
releases
, I was hoping to port that project's change log toreleases
too.This project didn't follow semantic versioning until very recently, so a lot of features went in to
1.2.x
releases.I see there's a
releases_unstable_prehistory
option which seems almost designed for this use case, but (as documented) this doesn't affect 1.0+ releases.What are your thoughts on this?
Thanks!
The text was updated successfully, but these errors were encountered: