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

Make releases easier and more frequent #1555

Closed
9 tasks done
jamadden opened this issue Apr 10, 2020 · 1 comment
Closed
9 tasks done

Make releases easier and more frequent #1555

jamadden opened this issue Apr 10, 2020 · 1 comment
Labels
internal Type: Enhancement

Comments

@jamadden
Copy link
Member

@jamadden jamadden commented Apr 10, 2020

gevent's yearly major release cadence is too slow, especially with CPython accelerating their release schedule from 18+months down to 12. Since pip and warehouse now conspire to hide "pre-release" versions, they might as well not exist—no one sees them or installs them by default.

We already have the policy of keeping master in a release-ready state at all times, so we might as well capitalize on that and make smaller "final" releases more frequently. That comes with its own set of challenges, most of which can be automated out of the way. (Inspiration comes from things like pip's release process.)

  • Decide an a release cadence. Every time there's some non-trivial change? Set a schedule? pip does the latter; most other projects I work on do the former, at the discretion of the project (e.g., a bunch of the changes I recently made to zope.interface were part of a theme and so I held of releasing 5.0 until all the PRs were created and merged). It's this faster cadence that drives the next change.
  • Switch to CalVer using YY.0M.Micro, e.g., the next release would be 20.04.0. This requires some of the other changes below.
  • Write a clear deprecation policy based on the cadence. Probably a year, to match CPython's schedule, roughly?
  • Figure out how to handle .. versionadded: and .. versionchanged: in docstrings. I'm thinking .. versionadded: NEXT is what's checked in, and at release time a script replaces those with the release version. zest.releaser can probably automate that.
  • Maybe use towncrier to generate CHANGES.rst. If so, integrate that with zest.releaser.
  • Document the release process.
  • Let Appveyor and Travis build and upload Windows, Manylinux and Mac wheels for releases. BTrees is a good example of this.
  • Add upper bounds to python_requires? Not strictly related but we've had lots of people installing gevent 1.4 on Python 3.8 (because of the no-pre-release thing that pip does), which is not supported.
  • Other documentation improvements: especially about building from source, e.g., alpine linux (#1567, #1562, #1559, #1566). This needs a callout in whatsnew_1_5.html
@jamadden jamadden added Type: Enhancement internal labels Apr 10, 2020
jamadden added a commit that referenced this issue Apr 16, 2020
jamadden added a commit that referenced this issue Apr 16, 2020
Refs #1555

Let testing work in manylinux when test.support isn't installed.

If test.support can't be imported many of the stdlib tests cant run either.
jamadden added a commit that referenced this issue Apr 16, 2020
Refs #1555

Let testing work in manylinux when test.support isn't installed.

If test.support can't be imported many of the stdlib tests cant run either.
jamadden added a commit that referenced this issue Apr 16, 2020
Refs #1555

Let testing work in manylinux when test.support isn't installed.

If test.support can't be imported many of the stdlib tests cant run either.
jamadden added a commit that referenced this issue Apr 16, 2020
Refs #1555

Let testing work in manylinux when test.support isn't installed.

If test.support can't be imported many of the stdlib tests cant run either.
oran-osc-github pushed a commit to o-ran-sc/ric-plt-a1 that referenced this issue Apr 20, 2020
Recent change in Gevent version 1.5.0 requires Alpine packages
file, make, libffi-dev to build the wheel.  Repair the broken
build by adding these packages to the Dockerfile. Also see
gevent/gevent#1555

Signed-off-by: Lott, Christopher (cl778h) <cl778h@att.com>
Change-Id: I5ec970f6f0b5594be5ac9f1abd693df098df749c
@jgehrcke
Copy link
Contributor

@jgehrcke jgehrcke commented Apr 24, 2020

Thank you @jamadden for your continued efforts, and this excellent level of clarity and transparency in your communications on GitHub.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal Type: Enhancement
Projects
None yet
Development

No branches or pull requests

2 participants