[x] Check Jenkins Status: should be green. (This should be checked often during the release process.)
[x] In coredev, check packages for updates: bin/manage report --interactive
[x] Release individual packages from checkouts.cfg.
[x] 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.
[x] Make a release candidate of Products.CMFPlone (e.g. 5.2.4rc1). Fine to release this on PyPI.
[x] Update coredev branch 5.2-dev. Empty the auto-checkout list in checkouts.cfg.
[x] Update the 5.2-dev directory on dist.plone.org and gather files to put there:
[x] Create a unified changelog based on the previous release: bin/manage changelog --start=5.2.X > release/changelog.txt. Remove the uninteresting top lines. Edit the Zope information.
[x] Create a release/RELEASE-NOTES.md. It may be enough to look through the changelog and copy interesting changes.
[x] Gather all package distributions.
You can use tox -c release/tox.ini -p auto to gather them in release/dist, together with a few other files.
[x] Get the versions.cfg file from coredev.
[x] Create a constraints.txt from this. The above tox command generates this and puts it in release/dist.
[x] Copy (rsync) all core packages and the other files to the pending release directory. I think we mostly do this so we have a backup if a version gets removed from PyPI.
[x] Write a post on community.plone.org announcing a pending/soft release. See example
[x] Wait for feedback, preferably at most a few days.
[x] Make final release of Products.CMFPlone to PyPI, update versions.cfg.
[x] Create tag of the release branch, e.g. 5.2.4, and push to GitHub.
[x] Make final release directory on dist.plone.org, make sure updated distributions, versions and constraints are added).
[x] Update the "-latest" links on dist.plone.org, e.g. ln -sfT 5.2.5 5.2-latest
[x] Announce community.plone.org, with warning that installers are not ready yet.
[x] Create an issue or PR for the Unified Installer. Should be only a search-and-replace.
See PR for Plone 5.2.6.
[x] Get the new installer from the GitHub Actions artifact of your PR, upload this to Launchpad, link on plone.org release page.
[x] Publish release page on plone.org. If the installer takes too long, publish it anyway. Coordinate with the Marketing Team.
[x] Marketing Team: Send out announcement to plone-announce, Twitter, update #plone irc channel topic, what you want.
[x] Ask the security team to update the https://plone.org/security/hotfixes/ page in the configuration control panel. (Configuration registry: plone.securitysupport, plone.versions, plone.activemaintenance)
bin/manage report --interactive
checkouts.cfg
.CMFPlone metadata.xml
and latestupgrade step
are in sync, and that they are higher than in the previous Plone release.mockup
andplone.staticresources
are in sync and can be released. Example: https://github.com/plone/mockup/issues/1026plone.restapi
andplone.rest
.Products.CMFPlone
(e.g. 5.2.4rc1). Fine to release this on PyPI.5.2-dev
. Empty theauto-checkout
list incheckouts.cfg
.5.2-dev
directory on dist.plone.org and gather files to put there:bin/manage changelog --start=5.2.X > release/changelog.txt
. Remove the uninteresting top lines. Edit the Zope information.release/RELEASE-NOTES.md
. It may be enough to look through the changelog and copy interesting changes.tox -c release/tox.ini -p auto
to gather them inrelease/dist
, together with a few other files.constraints.txt
from this. The above tox command generates this and puts it inrelease/dist
.rsync
) all core packages and the other files to the pending release directory. I think we mostly do this so we have a backup if a version gets removed from PyPI.Products.CMFPlone
to PyPI, updateversions.cfg
.ln -sfT 5.2.5 5.2-latest
bin/manage launchpad <version>
plone.securitysupport
,plone.versions
,plone.activemaintenance
)