It does look like we can use another alpha release. Biggest blockers for beta: getting a Volto 16 alpha release with Slate, and having the installation documentation merged.
[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 an alpha/beta/release candidate release of Products.CMFPlone (e.g. 6.0.0a1, later 6.0.0b1 and 6.0.0rc1). Fine to release this on PyPI.
[x] Adjust coredev branch release/6.0-dev. Most importantly, the auto-checkout list in checkouts.cfg should be empty, and the versions.cfg and requirements.txt should be the same.
[x] Update the 6.0-dev directory on dist.plone.org, and gather files to put there:
[x] You can use tox -c release/tox.ini -p auto to create or copy some files in release/dist. But you need to create some of those files first.
[x] Create a unified changelog based on the previous release: bin/manage changelog --start=6.0.0a1 > release/changelog.txt. Remove the uninteresting top lines.
[x] Create a file release/RELEASE-NOTES.md. It may be enough to look through the changelog and copy interesting changes.
[x] Get the versions.cfg file from coredev.
[x] Create a release/constraints.txt file from this. The above tox command generates this. Note: at some point I expect the constraints file to become leading, and we may need to generate a versions.cfg file instead.
[x] Copy (rsync) these files to the pending release directory. (We used to copy packages as well, but let's not do this for Plone 6 anymore.)
[x] Write a post on community.plone.org announcing a pending/soft release. See example. In the 6.0 alpha/beta/rc stage, we can skip pending releases and just make a real release.
[x] Wait for feedback, preferably at most a few days. As said, in the alpha/beta/rc stage, we can probably skip this.
[x] Make final release of Products.CMFPlone to PyPI, update versions.cfg.
[x] Create tag of the release branch, e.g. 6.0.0a1, and push to GitHub.
[x] Make final release directory on dist.plone.org, with versions, requirements, constraints, changelog, release notes.
[x] Update the "-latest" links on dist.plone.org, e.g. ln -sfT 6.0.0a1 6.0-latest
[x] Create new release on launchpad (https://launchpad.net/plone/): bin/manage launchpad <version>. Actually, since we do not create and upload universal installers for Plone 6, we could probably skip this.
[x] Notify Erico, perhaps on the #install-and-deploy Discord channel, that there is a new release. He can create Docker images then.
[x] Announce on community.plone.org. Perhaps wait until the Docker images are there, but don't wait long.
[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)
mauritsvanrees
commented
2 years ago
It does look like we can use another alpha release. Biggest blockers for beta: getting a Volto 16 alpha release with Slate, and having the installation documentation merged.
Smaller items before I want to release the alpha:
plone.voltoreleaseplone.app.localesreleaseSee the release schedule.
bin/manage report --interactivecheckouts.cfg.CMFPlone metadata.xmland latestupgrade stepare in sync, and that they are higher than in the previous Plone release.plone.restapiandplone.rest, and maybeplone.volto.Products.CMFPlone(e.g. 6.0.0a1, later 6.0.0b1 and 6.0.0rc1). Fine to release this on PyPI.release/6.0-dev. Most importantly, theauto-checkoutlist incheckouts.cfgshould be empty, and theversions.cfgandrequirements.txtshould be the same.6.0-devdirectory on dist.plone.org, and gather files to put there:tox -c release/tox.ini -p autoto create or copy some files inrelease/dist. But you need to create some of those files first.bin/manage changelog --start=6.0.0a1 > release/changelog.txt. Remove the uninteresting top lines.release/RELEASE-NOTES.md. It may be enough to look through the changelog and copy interesting changes.release/constraints.txtfile from this. The above tox command generates this. Note: at some point I expect the constraints file to become leading, and we may need to generate aversions.cfgfile instead.rsync) these files to the pending release directory. (We used to copy packages as well, but let's not do this for Plone 6 anymore.)Products.CMFPloneto PyPI, updateversions.cfg.ln -sfT 6.0.0a1 6.0-latestbin/manage launchpad <version>. Actually, since we do not create and upload universal installers for Plone 6, we could probably skip this.#install-and-deployDiscord channel, that there is a new release. He can create Docker images then.plone.securitysupport,plone.versions,plone.activemaintenance)