1.3.0 Release

[neersighted]

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.py by default (build: do not generate setup.py by default poetry-core#318)

[finswimmer]

Nice to have:

• feat(cli): add cli option to specify working path #6810
• fix: make AUTHOR_REGEX less restrictive poetry-core#517

[dimbleby]

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:

• 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

edit: I forgot about poetry-core, let's add

• Use file:// urls for path and directory dependencies poetry-core#512
• respect metadata_directory poetry-core#487

(though acknowledging that they're both mine, perhaps I'm biased)

[dimbleby]

#6747 is maybe also desirable (needs a poetry-core release first)

[neersighted]

Edited; I'll start taking a look at finishing/merging the low hanging fruit later today.

[rickzinit]

any possibility to release v.1.3.0 this week?

[neersighted]

As ever, soon/when we can.

[neersighted]

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]

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]

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]

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]

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]

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]

Cleo 2.0.0 (nee 1.0.0) is pulled in for this release; and poetry-core 1.4.0 is tagged and ready for dependent PRs to be rebased on.

[neersighted]

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]

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]

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]

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.