Skip to content

Commit

Permalink
Release version 11.0
Browse files Browse the repository at this point in the history
  • Loading branch information
@aaugustin
aaugustin committed Apr 2, 2023
1 parent 7dd4ede commit f516cf5
Show file tree
Hide file tree
Showing 2 changed files with 2 additions and 3 deletions.
3 changes: 1 addition & 2 deletions docs/project/changelog.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -25,11 +25,10 @@ fixing regressions shortly after a release.
Only documented APIs are public. Undocumented, private APIs may change without
notice.


11.0
----

*In development*
*April 2, 2023*

Backwards-incompatible changes
..............................
Expand Down
2 changes: 1 addition & 1 deletion src/websockets/version.py
View file
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@
# When tagging a release, set `released = True`.
# After tagging a release, set `released = False` and increment `tag`.

released = False
released = True

tag = version = commit = "11.0"

Expand Down

11 comments on commit f516cf5

@kloczek
Copy link

Choose a reason for hiding this comment

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

Please meke next time github release a well because github sends watch notification only if it is new entry in https://github.com/python-websockets/websockets/releases

@aaugustin
Copy link
Member Author

Choose a reason for hiding this comment

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

Unfortunately, you cannot get information about new versions via GitHub notifications because I don't use GitHub releases.

@kloczek
Copy link

Choose a reason for hiding this comment

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

Is it possible to add such additional step? 🤔
It would allow use such async noityfications to check quicker new release by more people ..

@aaugustin
Copy link
Member Author

Choose a reason for hiding this comment

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

GitHub automatically generates archives (.zip and .tar.gz) for releases that aren't valid Python packages. There's no way to prevent it. In the past, on another repo, I ran in trouble with people using these archives to install my libraries. That's one of the reasons why I stopped using GitHub releases. The other reason is that it takes quite a bit of manual work to copy and reformat the changelog.

Generally speaking, I would recommend against GitHub notifications for checking if your dependencies are up-to-date. There's a range of tools, including but not limited to dependabot, pip-tools, or poetry, that can be configured to do this with more or less automation, depending on your favorite workflow.

@kloczek
Copy link

Choose a reason for hiding this comment

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

GitHub automatically generates archives (.zip and .tar.gz) for releases that aren't valid Python packages.

No one is going to use such tar balls as pyhon packages.
However using such tar balls as input resource to produce package makes sense in 100%.
Especially if it is used packaging layer like rpm or other to provide plaform on which will be guaranteed that it will be easy to integrade in build processs any patch from VCS..

[tkloczko@pers-jacek SPECS]$ ls -1 python-*.spec | wc -l; grep "Source:         %{VCS}" python-*| wc -l; grep "Patch:           %{VCS}" python-* |wc -l
1130
1041
598

So above says that I have ATM +1130 spec files with description of building rpm packages with python modules.
1041 are using as input resource tar ball autogenerated from git tags
All those packages which are usimng VCS tar balls have now integrated almost 600 patches taken directly from exact commits hashes.

I wantoi only to say that we are living in th worrld in which we are dealing with software with many bugs.
It doesn't matter how many of those bugs are still around.
Most important is how quicluy single bug can be soted out and what is total COST of fixing exact issue.
using standard python tooling for now is not possible to provide so low cost as in this case ..

I have already some automations which is processesing release notyfications trying to automatically build new version and if such new package builds correctly and passess some qualification tests only at the end human is involved to approve use of new package version.
In other words such notyfications saves in my distro a lot of time 😋
With that automation working soon I should be able provide automatically generated fidback notyfications that something went wrong.
You will scratch my back and I will do the same 😛

@aaugustin
Copy link
Member Author

Choose a reason for hiding this comment

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

Ah, it looks like we're facing the divergent concerns between "library maintainers" and "distro maintainers".

(I don't know if you're actually "maintaining a distro". At least, you're building RPM packages and installing them system-wide rather than downloading Python wheels and installing them in a virtualenv. So the concerns are the same.)

Now, we have two separate issues here.

  1. Downloading the code for a given version as an archive (rather than a git clone)

Since I tag versions, you can download an archive from GitHub:

I believe this should do the job.

  1. Getting notifications when a new release happens

I don't believe that GitHub is the best place for this as far as Python packages are concerned. The standard in the Python community is to release packages to PyPI. This is the most complete database. It doesn't depend on whether a package is maintained on GitHub or elsewhere, what the release workflow looks like, etc.

You can access this information automatically from PyPI:

  • with a RSS feed for all packages: curl https://pypi.org/rss/updates.xml (then you have look for packages you care about in the stream)
  • with a RSS feed for a single package: curl https://pypi.org/rss/project/websockets/releases.xml (requires scripting 1130 calls)
  • from the API: curl https://pypi.org/pypi/websockets/json | jq -r .info.version (same)

Even better, you can probably get one source of information for packages written in multiple languages with Libraries.io. I'm not super familiar but I think it's what you want. That should be more robust and easier than getting all maintainers to use GitHub releases.

@kloczek
Copy link

@kloczek kloczek commented on f516cf5 Apr 27, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

I don't believe that GitHub is the best place for this as far as Python packages are concerned. The standard in the Python community is to release packages to PyPI

If you will look currently on any Linux, *BSD or even Solatis (Nexenta, OmniOS or Oracle Solaris) distibution you will find that all of those OS distrybutionsfrom from many years no longer relies on what pip can do but are trying to form set of packages between which is guaranteed consistency and are fixed known and/or JFDI issues.
That is for what sometimes some clients are paying for.

pip is not the tool which has been developed in mind for such things and only relies on what is published on pypi.
As sometimes python modules maintainers are busy/lazy/don't want to release new version after already fixing in git repo some already identified issue there is no other way to deal with how to provide such set of modules with proper ballance of functionality and possible lowest level of known bugs than just use OS level package management tooling.
It is really so simple ..

GH notyfications are only mechanizm which could trigger some additional automatic or manual steps to test new vesion of the software.
Only this and nothing more.

Create GH release it is inly one command .. https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository?tool=cli.
You can do that as well directly over GH API using curl or if do that manually if you wish.
If you have alredy some defined process of release new verion (as for example script) with publishing results on pypi and tagging git repo it will be just yet another line in that definition.

@aaugustin
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 filed an issue to keep track of this discussion: #1347

I'm not 100% decided yet. If the cost of maintenance is low, I could do it.

PS: your last message makes it very clear that we're in the usual distro maintainer vs. library developer tension...

@kloczek
Copy link

Choose a reason for hiding this comment

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

Thank you 👍

@aaugustin
Copy link
Member Author

Choose a reason for hiding this comment

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

Assuming #1351 works as designed you'll get a GitHub Release for future releases. You have them for all past releases, too, including the new one I made today.

@kloczek
Copy link

@kloczek kloczek commented on f516cf5 May 7, 2023

Choose a reason for hiding this comment

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

Yep it works 👍
Thank you 😄

Please sign in to comment.