Closed hameerabbasi closed 5 years ago
Bugs that are only included in major releases need to be marked as "major bugs" so the algorithm knows where they're supposed to live - search for 'major' here: https://releases.readthedocs.io/en/latest/usage.html - thanks!
It’s actually the other way around if you look at the source and the generated page. Minor bugfixes aren’t included in a major release.
If you see the source, the release is at the top but the bugs below it aren’t included in it.
I think you missed what I meant. Without any additional annotations, :bug:
entries only show up in "bugfix" level releases - e.g. 1.2.3. It's considered implicit that major releases include any regular bugs that came before them (why would somebody revert a bugfix released in, say, version 2.1.3 when they put out a later version 2.2.0?).
If you have a bug that was only truly released in a non-bugfix release (i.e. this bug really did only come out in version 2.2.0), it must be marked as major
to note that it's a big, serious bug, which puts it on the same footing as a :feature:
style entry.
I understand what you're saying. But the issue here is different, no one is reverting a bugfix.
It just so happened that I fixed some bugs after 0.3.1
was released and they made it into 0.4.1
(0.4.0
was skipped for unrelated reasons), but they are not yet backported to 0.3.x
yet.
Although I put the :release:
tag for 0.4.1
above the bugs, the releases page still says that the bugs will be fixed in the release after that. A minor release should implicitly include all bugs that came before the :release:
tag -- Why would someone fix bugs and then make a release without them, even if it's a minor release and not a bugfix release?
Minor bugfixes weren't included in a major release for me.
See http://sparse.pydata.org/en/0.4.1/changelog.html and the file that generated it https://raw.githubusercontent.com/pydata/sparse/8872e094ea1fa0866ea3b2bef5d3aa658827d009/docs/changelog.rst