mitiq
mitiq copied to clipboard
remove patch release docs
Description
We recently did a patch release and I followed the instructions for a standard release, only to later find that we have patch release specific docs. I understand it would be nice to only include the commits for the patch, but it seems like more work than is necessary. WDYT about just doing patch releases the same way we do 'regular' releases?
Codecov Report
Merging #1435 (81a1152) into master (47e915c) will not change coverage. The diff coverage is
n/a
.
@@ Coverage Diff @@
## master #1435 +/- ##
=======================================
Coverage 98.19% 98.19%
=======================================
Files 62 62
Lines 2819 2819
=======================================
Hits 2768 2768
Misses 51 51
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
Sounds good. I've assigned @Misty-W to take a look when she's back.
In qutip there is a cherry-pick option for bug fixes, maybe changing the docs to reflect this (rather than tying this to a semantic versioning standard) could help have more freedom (e.g., in disregarding cherry-picking if not needed)? https://qutip.org/docs/latest/development/release_distribution.html#create-a-bug-fix-release
The qutip docs are great, and very detailed. I think we could use a modified version of their release protocol with our workflow, but it would require some changes as we currently release from master and qutip release from feature branches. I don't think it would be a major change, but it would require some work. With the testing required to ensure the docs are correct, I'm not sure it's worth our time to do this since we don't seem to patch release frequently. In fact, have we ever done a patch release following these docs?
On the release page, it lists 0.9.3, 0.9.4, 0.11.1 as patch releases, although I did not check if in those cases the cherry pick was used. I still think that having a clue for how to include cherry picks can be useful but I also think we can use better our time than discussing extensively this minor topic, so I'll approve. No need the way we release in general.