Repository navigation
Huge number of bugs for a patch release version 1.1.8 - reconsider how releases are versioned #4429
Description
We have opted to use poetry for our releases at work to reduce our dev-ops issues by allowing us to rely on stable semantically versioned libraries. However version 1.1.8 has been a major source of dev-ops failures for us.
It took us a long time to release that the source of our bugs was a PATCH version of poetry specifically version 1.1.8. The issue we had was #4414 which stopped any of our docker containers from working. We have reverted our poetry version to 1.1.7, which has fixed our issues. However looking at the issue list for this release makes me wonder if poetry a version management tool, which relies on other projects using semver correctly adheres to correct version management itself. As a patch version should not include major breaking changes.
Specifically one glance at the issues page yields:
#4427 #4422 #4414 #4413 and presumably a few others, which are not tagged explicitly as 1.1.8.
As aforementioned semver exists so that developers know what degree of bugs / changes in the api to expect. Patch versions are meant to fix bugs not add them. https://semver.org/
I would like to propose:
- Poetry uses semver correctly / considers it's release process a bit more and only releases bugfixes on a PATCH version and more major breaking changes like this on a major or minor release version (though this one should probably have been an alpha).
- Quickly re-release version 1.1.7 as 1.1.9 so that fewer people get hit by the bugs released by 1.1.8 -> the releases of 1.1.8 can go back to a beta release before people start adding hacky work arounds to their dev ops for the 1.1.8 bugs.
Bar this one release we have loved using poetry so far, so we hope that the release stability improves as the poetry team have made a fantastic product.
Activity
[-]Huge number of bugs for a minor release version 1.1.8 - reconsider how releases are versioned[/-][+]Huge number of bugs for a patch release version 1.1.8 - reconsider how releases are versioned[/+]finswimmer commentedon Aug 23, 2021
Hello @mcsheehan,
I can understand your frustration about the problems with poetry 1.1.8 and I'm very sorry about it.
The issues you've linked (and probably some others) have all the same root cause: #4407 We underestimate how hard it is to reliable find out the systems python interpreter if needed. What it makes so complicated, is that poetry can be installed in many different ways (
install-poetry.py,get-poetry.py, pip(x)). We are working on it. As a first step the latest changes that leads to the issues will be reverted.What could help us to avoid those release issues is to have the ability to test several end-to-end use cases, which include poetry installation in various ways, creating projects, adding/removing dependencies, run with different config option, ... We would really appreciated to get some help from others.
That's the problem with bugs. If I would knew that my release contains bugs, I wouldn't release it ;) Semver versions reflect the intention of changes by the maintainer. Even a (successfully) bug fix can be a major breaking change to someone else (That's why some people argue Semver is useless or broken). The release was meant to fix bugs, so increasing the patch version was right.
So again, me and the poetry team are very sorry about the current problems.
fin swimmer
(I'm closing this issue, because it's more a discussion and I hope I could address your points. If there is more communication needed, please use GH discussions for it or join our discord server.)
max-wittig commentedon Sep 27, 2021
Maybe also related to #4266
github-actions commentedon Mar 2, 2024
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.