Porting projects with non-semver history

bitprophet / releases

A powerful Sphinx changelog-generating extension.

http://releases.readthedocs.io/

BSD 2-Clause "Simplified" License

176 stars 41 forks source link

Porting projects with non-semver history #58

Open AndreLouisCaron opened 8 years ago

AndreLouisCaron commented 8 years ago

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 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!

bitprophet commented 8 years ago

+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 :)

AndreLouisCaron commented 8 years ago

I'm pretty busy ATM, but I'll see if I can play around with the code.

brainwane commented 6 years ago

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.