Release checklist Plone 6.1.1

[mauritsvanrees]

Release packages, update versions

• Check Jenkins Status: should be green. (This should be checked often during the release process.)
• In coredev, check packages for updates: bin/manage report --interactive. This is less needed now that we have mr.roboto to add packages to the checkouts. Use bin/versioncheck to see if any new PyPI releases are worth adding, or check the artifact of the versioncheck GitHub Action.
• Release individual packages from checkouts.cfg.
• Check that the version numbers of CMFPlone metadata.xml and latest upgrade step are in sync, and that they are higher than in the previous Plone release.
• Handle special packages, often handled by special people. :-) You can can ping people in the release-team channel on Discord, in the current issue, or individually:
  • plonetheme.barceloneta and plone.staticresources need a release on PyPI and npmjs. Maybe plone.classicui. Ask Peter Mathis (petschki), Johannes (thet) or Maik (MrTango).
  • plone.restapi and maybe plone.volto. Ask David (davisagli) or Timo (tisto).
  • plone.app.locales. Ask Mikel (erral).
  • Release plone.app.upgrade, Plone and Products.CMFPlone yourself.
  • Update the versions of those packages in versions.cfg. This is done automatically if you are in a checkout of the package within buildout.coredev and run ../../bin/fullrelease. Or run bin/manage set-package-version package-name new-version.

Release notes, constraints, dist.plone.org

• Adjust coredev branch release/6.1-dev. Most importantly, the auto-checkout list in checkouts.cfg should be empty, and the versions.cfg and requirements.txt should be the same. One way that works for me: git switch release/6.1-dev; git reset --hard 6.1; git reset origin/release/6.1-dev; git checkout .package_ignores checkouts.cfg last_commit.txt mxcheckouts.ini. Then check which remaining changes you want to commit.
• Update the 6.1-dev directory on dist.plone.org, and gather files to put there:
  • Create a unified changelog based on the previous release: bin/manage changelog --start=6.1.0a1 > release/changelog.txt. Remove the uninteresting top lines. You may want to link to the Zope changelog with a specific tag.
  • Create a file release/RELEASE-NOTES.md. It may be enough to look through the changelog and copy interesting changes.
  • Get the versions*.cfg file and any other versions files from coredev.
  • NEW. Run make install. This uses mxdev to install packages and generate some files. Most importantly this generates constraints-mxdev.txt. This contains all constraints, and makes sure no constraints are in there twice (provided that mx.ini is correct). This is really the only constraints file that is needed and that is correct. So for now I will only ship this one and call it constraints.txt on dist.plone.org. This may need some more thought and updates in next releases.
  • Use tox -c release/tox.ini to copy these files to release/dist.
  • Copy (rsync) these files to the pending release directory: scp release/dist/* dist.plone.org:release/6.1-dev/

Final release, Docker

• Create tag of the release/6.1-dev branch, e.g. 6.1.0a1, and push to GitHub.
• Make final release directory on dist.plone.org, with versions, requirements, constraints, changelog, release notes.
• Update the "-latest" links on dist.plone.org, e.g. ln -sfT 6.1.0a1 6.1-latest
• Create a pull request for the plone-backend Docker image with the new version number. Get this reviewed, merged, tagged, released.

Announcements

You probably want to wait until the Docker images are there, but don't wait long.

• Create release page on https://plone.org/download/releases. This currently needs the Classic UI and some workarounds:
  • Go to the https://plone.org/ClassicUI/failsafe_login_form and login. Not with your GitHub username, but a special user. Ask the A/I team if you don't know.
  • In https://plone.org/ClassicUI/download/releases/ add a new Plone Release.
  • In the text you need the html of release notes. What I do: create a new post on community.plone.org, copy the release notes (MarkDown) in there, copy the html output, and save as a draft. Then paste the html in the Release notes field. Copy changelog.txt in the other field.
  • Go to the folder contents: https://plone.org/ClassicUI/download/releases/folder_contents. Go to the last batch page, and move the new release to the top of the folder.
  • Go to the ZMI: https://plone.org/ClassicUI/download/releases/manage_main. Rename plonerelease to new version number.
  • The rest can be done on the Volto side.
• Publish release page on plone.org.
• Update the https://plone.org/security/hotfixes/ page.
• Update the release schedule: note the new release, and say when the next release in this series is expected.
• Edit the link on https://plone.org/download.
• Announce on community.plone.org.
• Maybe make a PR for docs.plone.org, search and replace the previous bugfix or minor release number. Currently nothing to do in a bugfix release.
• Send mail to Marketing Team so they can prepare announcements.
• Ask Philip Bauer and/or Fred van Dijk to update the demo sites. Here is a sample PR. Mostly just a search and replace, except when you want to update Volto as well.

[mauritsvanrees]

I want to make a 6.1.1 release in the second half of next week.
@davisagli @petschki @erral Could you make releases please?

This time I actually first want to make a release candidate, maybe already tomorrow. Reason: it would be useful to have people test all those bloody pkg_resources changes in some projects. It is totally fine if there are for example no plone.app.locales changes in the rc, we can have those package releases next Monday/Tuesday.
Maybe no Docker image either for the rc, though we could still do that.

[davisagli]

@mauritsvanrees I released plone.restapi 9.13.0 and plone.volto 5.0.4.

The dists are named plone_restapi-9.13.0.tar.gz and
plone_restapi-9.13.0-py3-none-any.whl; I wonder if I should pin the build-system setuptools to <=75.8.0 and release 9.13.1 so that we have a name without an underscore for Plone 5.2...

[stevepiercy]

Maybe make a PR for docs.plone.org, search and replace the previous bugfix or minor release number. Currently nothing to do in a bugfix release.

This one should be updated for 6.1.x releases as follows. We no longer have a replacement variable for bugfix releases.

In plone/documentation's conf.py, update SUPPORTED_PYTHON_VERSIONS_PLONE61 as needed. Ask Steve Piercy or do it yourself.

For a future major or minor version release, we will need to update PLONE_BACKEND_MINOR_VERSION, currently located at https://github.com/plone/documentation/blob/6.0/docs/conf.py#L445.

[erral]

@mauritsvanrees the release should be from the branch where we have implemented the native namespaces?

[mauritsvanrees]

@mauritsvanrees the release should be from the branch where we have implemented the native namespaces?

@erral No, that would be for 6.2, and coredev is not yet ready to handle native namespaces.

[mauritsvanrees]

The dists are named plone_restapi-9.13.0.tar.gz and plone_restapi-9.13.0-py3-none-any.whl; I wonder if I should pin the build-system setuptools to <=75.8.0 and release 9.13.1 so that we have a name without an underscore for Plone 5.2...

Yes, for support of Plone 5.2 on Python 3.8 that sounds good. setuptools 75.3.2 was released two days ago with a back port of fixes for Python 3.8, and this makes it possible on Python 3.8 to generate the wheels with the new names, so I suppose it would then also be possible to properly install them with that version. But for zc.buildout there is no version on 3.8 that handles this.

For clarity: the underscores in the tarball are fine for 3.8, they have been generated that way since setuptools 69.0.3.

[erral]

Released plone.app.locales = 6.0.30

[davisagli]

@mauritsvanrees I released plone.restapi 9.13.1 with a backwards-compatible wheel name.

Is it possible to backport the fix in buildout to a version that supports Python 3.8? I can imagine it will continue to come up with other packages...

For clarity: the underscores in the tarball are fine for 3.8, they have been generated that way since setuptools 69.0.3.

This was a really helpful clarification, otherwise I would have gone down a rabbit hole trying to figure out why the sdist name was still wrong :)

[mauritsvanrees]

Is it possible to backport the fix in buildout to a version that supports Python 3.8?

I don't see myself doing that.

[mauritsvanrees]

I have released Plone 6.1.1rc1. Please test it on your projects.
Here are the release notes.

Please read the "Distribution not found" section carefully. We can rephrase this for the 6.1.1 final release next week.

[davisagli]

@mauritsvanrees I released plone.restapi 9.13.2 with fixes for several regressions. We should include it in 6.1.1 and 6.0.15 if possible.

[petschki]

I've released

plone.staticresources = 2.2.5
plonetheme.barceloneta = 3.2.3

@plone/mockup = 5.3.4
@plone/plonetheme-barceloneta-base = 3.2.3

[mauritsvanrees]

We will need a second release candidate for both 6.1 and 6.0 because some pkg_resources fixes are missing. See #4126 (comment)

[mauritsvanrees]

I have made all package releases for 6.1.1 final. https://dist.plone.org/release/6.1.1/ is live. plone-backend Docker PR needs an approving review: plone/plone-backend#185

[mauritsvanrees]

Announcement has been done:

• https://community.plone.org/t/plone-6-1-1-released/21627
• https://plone.org/download/releases/6.1.1

[pbauer]

Demo-Sites PR: plone/demo.plone.org#70

[mauritsvanrees]

Then we are done. Thank you all!