search

bitprophet / releases

A powerful Sphinx changelog-generating extension.
http://releases.readthedocs.io/
BSD 2-Clause "Simplified" License
176 stars 41 forks source link

Add support for implicit .0 in minor/feature releases? #57

Open nonatomiclabs opened 8 years ago

nonatomiclabs commented 8 years ago

I have the following changelog:

* :release:`1.1 <2016-03-11>`
* :feature:`-` New feature
* :release:`1.0 <2016-03-10>`
* :feature:`-` Initial release

The "New feature" will appear in the category "Next feature release", even though from a version number point of view the "1.1" is a feature release.

If I add the third version number, it works:

* :release:`1.1.0 <2016-03-11>`
* :feature:`-` New feature
* :release:`1.0.0 <2016-03-10>`
* :feature:`-` Initial release

I think it's a valid use case to use only two version numbers. The funny thing is that if we change the "New feature" to be a "bug", it'll be included in the "1.1", etc.

Even though you decide not to fix it, it might deserve a couple of lines in the documentation ;)

Python 2.7.10
releases 1.2.0
bitprophet commented 8 years ago

Thanks for reporting this!

I think it's a valid use case to use only two version numbers

Unfortunately, that's not how Releases was designed, so you're operating outside defined scope :( Honestly surprised you're not getting an exception in this case. All tests and all real-world use has 3-part version numbers.

I wouldn't be crazy opposed to having 1.1 behave implicitly like 1.1.0, but it'll definitely need some sort of patch for that to work.

(Re: why switching the feature to a bug makes it "work", see the conceptual docs - features and bugs have different rules for which releases pull them in by default.)