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 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
The text was updated successfully, but these errors were encountered:
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.)
bitprophet
changed the title
Releases containing only primary and secondary numbers change releases category
Add support for implicit .0 in minor/feature releases?
Jun 23, 2016
I have the following changelog:
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:
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 ;)
The text was updated successfully, but these errors were encountered: