Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 1.1.0a7 #289

Merged
merged 1 commit into from
Mar 5, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 42 additions & 1 deletion CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,45 @@
# Change Log

## [1.1.0a7] - 2022-03-05

### Fixed

- Fixed an issue when evaluate `in/not in` markers ([#188](https://github.com/python-poetry/poetry-core/pull/188)).
- Fixed an issue when parsing of caret constraint with leading zero ([#201](https://github.com/python-poetry/poetry-core/pull/201)).
- Respect format for explicit included files when finding excluded files ([#228](https://github.com/python-poetry/poetry-core/pull/228)).
- Fixed an issue where only the last location was used when multiple packages should be included ([#108](https://github.com/python-poetry/poetry-core/pull/108)).
- Ensure that package `description` contains no new line ([#219](https://github.com/python-poetry/poetry-core/pull/219)).
- Fixed an issue where all default dependencies were removed instead of just the selected one ([#220](https://github.com/python-poetry/poetry-core/pull/220)).
- Ensure that authors and maintainers are normalized ([#276](https://github.com/python-poetry/poetry-core/pull/276)).

### Added

- Add support for most of the guaranteed hashes ([#207](https://github.com/python-poetry/poetry-core/pull/207)).
- Add support to declare multiple README files ([#248](https://github.com/python-poetry/poetry-core/pull/248)).
- Add support for git sub directories ([#192](https://github.com/python-poetry/poetry-core/pull/192)).
- Add hooks according to PEP-660 for editable installs ([#182](https://github.com/python-poetry/poetry-core/pull/182)).
- Add support for version epochs ([#264](https://github.com/python-poetry/poetry-core/pull/264)).


### Changed

- Drop python3.6 support ([#263](https://github.com/python-poetry/poetry-core/pull/263)).
- Loose the strictness when parsing version constraint to support invalid use of wildcards, e.g. `>=3.*` ([#186](https://github.com/python-poetry/poetry-core/pull/186)).
- No longer assume a default git branch name ([#192](https://github.com/python-poetry/poetry-core/pull/192)).
- Sort package name in extras to make it reproducible ([#280](https://github.com/python-poetry/poetry-core/pull/280)).

### Improvements

- Improve marker handling ([#208](https://github.com/python-poetry/poetry-core/pull/208),
[#282](https://github.com/python-poetry/poetry-core/pull/282),
[#283](https://github.com/python-poetry/poetry-core/pull/283),
[#284](https://github.com/python-poetry/poetry-core/pull/284),
[#286](https://github.com/python-poetry/poetry-core/pull/286),
[#291](https://github.com/python-poetry/poetry-core/pull/291),
[#293](https://github.com/python-poetry/poetry-core/pull/293),
[#294](https://github.com/python-poetry/poetry-core/pull/294),
[#297](https://github.com/python-poetry/poetry-core/pull/297)).

## [1.1.0a6] - 2021-07-30

### Added
Expand Down Expand Up @@ -213,7 +253,8 @@ No changes.
- Fixed support for stub-only packages ([#28](https://github.com/python-poetry/core/pull/28)).


[Unreleased]: https://github.com/python-poetry/poetry-core/compare/1.1.0a6...master
[Unreleased]: https://github.com/python-poetry/poetry-core/compare/1.1.0a7...master
[1.1.0a7]: https://github.com/python-poetry/poetry-core/releases/tag/1.1.0a7
[1.1.0a6]: https://github.com/python-poetry/poetry-core/releases/tag/1.1.0a6
[1.1.0a5]: https://github.com/python-poetry/poetry-core/releases/tag/1.1.0a5
[1.1.0a4]: https://github.com/python-poetry/poetry-core/releases/tag/1.1.0a4
Expand Down
2 changes: 1 addition & 1 deletion pyproject.toml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
[tool.poetry]
name = "poetry-core"
version = "1.1.0a6"
version = "1.1.0-alpha.7"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason why the naming pattern is changed? And why is it changed here, but not in __init__.py?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point 👍 I bumped the version via poetry version and this uses SemVer nomenclature in the pyproject.toml. I guess this was done before manually.

I've change the __init__.py file to read the version now via importlib. So we can avoid duplicate places for the version number.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've change the init.py file to read the version now via importlib. So we can avoid duplicate places for the version number.

hm, seems to be problematic, because poetry-core needs to build itself. Will revert it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, but both "versions" should at least be equal, shouldn't they?

Copy link
Member Author

@finswimmer finswimmer Mar 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jaein :) Within the __init__.py file the version should follow PEP 440. When poetry installs the package it translate the semver notation from the pyproject.toml into a PEP 440 compliant form. Whether poetry should create the version in the pyproject.toml in PEP 440 by default is another story, which we should discuss at some point.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While reading the part about normalization, I thought the same: "seems to be valid, just not normalized". However, the part about compatibility with semantic versioning says "Semantic versions containing a hyphen (pre-releases - clause 10) or a plus sign (builds - clause 11) are not compatible with this PEP and are not permitted in the public version field."

Maybe, versions which are not normalized are not considered PEP440 compliant but only have to be tolerated for compatibility reasons?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or, you could avoid all this confusion by releasing plain old 1.1.0...

What is the reason for alpha releases of poetry-core? Just ship what's good now, and ship fixes / additions / changes in 1.1.1 / 1.2.0 / 2.0.0. There's no shortage of version numbers.

(Possibly a conversation for another place, but I'd encourage a poetry 1.2.0 release too... do point me at it if this is being discussed somewhere. There are lots of fixes stored up in master that are never going to get back-applied to the 1.1 branch, let's release them)

Copy link
Member Author

@finswimmer finswimmer Mar 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand PEP-440 in that way that -alpha.7 is compliant in that way, that parser have to accept it, but it's not allowed to write 🤷‍♂️

@dimbleby: I'm not sure at the moment if something is missing or to unstable to release a 1.1.0 of poetry-core. A poetry 1.2 is definitely not possible yet, because the plugin system is not enough stable.

So @python-poetry/core: Is there something that should be changed here now or can we go on releasing?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure at the moment if something is missing or to unstable to release a 1.1.0 of poetry-core

It's complete / stable enough to be used by poetry - as demonstrated by its master branch. I don't see users from any other projects asking for additions or fixes.

A poetry 1.2 is definitely not possible yet, because the plugin system is not enough stable.

Then my suggestion would be to cut a release, but declare that the plugin system is not yet stable.

(Unless there's some work to bring that desired stability which is nearing completion, in which case it might be worth waiting for it. But I get the impression that we are likely to be waiting for some time, and it's a shame to let the perfect be the enemy of the good.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed it whether we want to call the release 1.1.0. We decided to keep it as an alpha release until we are sure enough that there are no more big changes needed before the poetry 1.2.0 release.

description = "Poetry PEP 517 Build Backend"
authors = ["Sébastien Eustace <sebastien@eustace.io>"]

Expand Down
2 changes: 1 addition & 1 deletion src/poetry/core/__init__.py
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
from pathlib import Path


__version__ = "1.1.0a6"
__version__ = "1.1.0a7"

__vendor_site__ = (Path(__file__).parent / "_vendor").as_posix()

Expand Down