Repository navigation
1.3.0 Release #6972
Description
This issue tracks the progress of version 1.3.0 of Poetry. Please surface any blockers or concerns you have regarding this minor release here:
Blockers
- Changelog
- Release notes (blog)
- poetry-plugin-export 1.2.0 (release: bump version to 1.2.0 poetry-plugin-export#158)
- chore: re-lock Poetry's dependencies #6950
Nice to have
- feat(cli): add cli option to specify working path #6810
fix: make AUTHOR_REGEX less restrictive poetry-core#517- pip install --no-input everywhere #6966
- Relay return code as exit code when running script #6824
- [1.2] fix: fix support for packaging v20.4 #6808
- Unhittable value error #6790
- Clarifies the dev-dependencies -> group.dev.dependencies switch in docs #6723
Fix types as if cleo were typed #6709- Use file:// urls for path and directory dependencies poetry-core#512
- respect metadata_directory poetry-core#487
- Simplify analysis of locked packages #6747
Cleo 1.0.0 release checklist cleo#248
Important changes to surface
(This is intended to be the basis for the blog post and should cover new features or any manual steps/incompatibility when upgrading)
- The next release will turn off generation of
setup.pyby default (build: do not generate setup.py by default poetry-core#318)
Activity
finswimmer commentedon Nov 4, 2022
Nice to have:
dimbleby commentedon Nov 4, 2022
At time of writing, there are quite a lot of straightforward pull requests queued up. I don't think any of them should block a release - I'm in favour of releasing more often! - but also I don't know any reason they shouldn't be merged and included.
Trying to err on the side of caution, I'd still suggest that the following look ready to go:
edit: I forgot about poetry-core, let's add
(though acknowledging that they're both mine, perhaps I'm biased)
dimbleby commentedon Nov 5, 2022
#6747 is maybe also desirable (needs a poetry-core release first)
neersighted commentedon Nov 5, 2022
Edited; I'll start taking a look at finishing/merging the low hanging fruit later today.
rickzinit commentedon Nov 16, 2022
any possibility to release v.1.3.0 this week?
neersighted commentedon Nov 16, 2022
As ever, soon/when we can.
neersighted commentedon Nov 18, 2022
Regarding python-poetry/poetry-core#517, consensus is that we need to weigh it against python-poetry/poetry-core#521 (which looks promising but has poor tests/needs more exploration), and that neither should block release.
neersighted commentedon Nov 18, 2022
Regarding #6709, without CI to validate it, and with other work needed to migrate Poetry to the (eminent) 1.0 release, I am inclined to defer it to reduce risk and my need to manually validate the change.
python-poetry/cleo#248 would be nice, but we can bump Cleo in a patch release and @Secrus has limited bandwidth to get #6709 reviewed/Poetry rebased on top of the breaking changes in Cleo 1.0.
neersighted commentedon Nov 18, 2022
The status of 1.3 looks like this: we need a core release (and core is ready to release), then we need to rebase one PR against Poetry on our "nice-to-have" list to account for that. We can then review & merge that PR, prepare a version bump, and draft our release notes/CHANGELOG.
dimbleby commentedon Nov 18, 2022
re cleo, I have code sitting around locally that fixes up the remaining type errors if and when the cleo release happens.
So if cleo were to release 1.0 soon, and if y'all did want to get that into 1.3.0 - then it should be possible to move fast.
I don't know that that's especially desirable - I can think of a couple of useful bug-fixes, but nothing that couldn't wait for a 1.3.1 or whatever - and certainly I wouldn't advocate blocking poetry 1.3.0 on cleo.
neersighted commentedon Nov 18, 2022
That's pretty much where it's at -- there's not benefit to the partial approach before 1.0 is ready, and Cleo 1.0 is mostly blocked on bandwidth. What we have works, let's ship that and then we can use automated tooling to make changes for Cleo 1.0 with more confidence once it is tagged; then backport it if desired to make life easier to the distro packagers.
dimbleby commentedon Nov 18, 2022
Just so we're clear, I'm saying that Secrus bandwidth to rebase poetry on cleo 1.0 breaking changes need not be a factor, I have that done already.
(again, I'm nevertheless fully ok with not waiting for cleo)
neersighted commentedon Nov 22, 2022
Cleo 2.0.0 (nee 1.0.0) is pulled in for this release; and
poetry-core1.4.0 is tagged and ready for dependent PRs to be rebased on.neersighted commentedon Nov 22, 2022
We've surfaced a new blocker: #6950 is necessary to improve our CI coverage, and has revealed failures on Python 3.9 / Windows with a simple version bump. Resolving these failures (either as a false positive or as breakage we need to fix, or at the very least a dependency version we need to exclude using constraints) needs to be done before we can tag 1.3.0.
finswimmer commentedon Nov 27, 2022
If we have the time I would like to see #7100 in 1.3 as there are already other fixes regarding
virtualenvs.prefer-active-python.dimbleby commentedon Dec 8, 2022
Ship it!
I'm not sure what it is that causes poetry's release-paralysis - is the release process burdensome? is there anything the rest of us can do to make it not burdensome?
So far as I can see the codebase has been in a sensible state to cut a release for quite some time; let's do it, and move on to the next one.
(There's only so many times I can tell people to clear their cache, releasing the fixes is a much more scalable solution...)
github-actions commentedon Feb 29, 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.