Closed mauritsvanrees closed 1 year ago
@thet @petschki @erral @tisto I want to make a Plone 6.0.1 release. If possible a release candidate tomorrow (Friday), and a final release early next week. Release schedule says we want this in January. :-)
Could each of you make releases where necessary for plone.staticresources
, plonetheme.barceloneta
, plone.app.locales
, plone.restapi/volto
please?
I also want to release 5.2.11 but it looks like no further releases are necessary there.
@sneridagh Is latest Volto 16.8.1 fine for 6.0.1, or should we wait on some changes? I would usually just paste the latest version number when I write the release notes.
plone.app.locales = 6.0.10 released
@mauritsvanrees I'll try to release a 16.9.0 soon-ish, let's see tomorrow. I'll let you know.
@mauritsvanrees I'm waiting for @patternslib/patternslib==9.8.1
which will be released soon (this weekend?) by @thet and release plone.staticresources==2.0.5
afterwards.
@mauritsvanrees note: as Peter Holzer has a new job since last year and cannot actively develop Plone anymore 😢 I'll do the plonetheme.barceloneta
and @plone/plonetheme-barceloneta-base
package releases on pypi and npmjs in the future.
/cc @agitator ok with you?
I will make a 6.0.1 release candidate with the releases that are here now. There will be another Plone release within one month, so I don't think there is a great need to wait for individual packages.
I am thinking of creating a fixed schedule, like: every fix that is in on the 20th of the month will go into a new Plone bugfix release. Or the third Monday of the month, something like that. Make it clear to everyone, so expectations are clear. After that, it is at the discretion of the release manager, who should of course still be open to suggestions. And I would still do a ping in an issue like this one to get final releases in. Allow three days or so to get individual packages released. Then I create the release candidate.
This is not a critique on anyone. Every package or set of packages has its own dynamic, where for example staticresources depends on the state of mockup and Patternslib, and we need a good combination of plone.restapi, plone.volto and Volto. It is just so easy for me to get drawn into checking pull requests for individual packages, to make sure every last available fix is in the release and working stably together, resulting in a delay of getting already existing and released fixes out to users. I like to avoid that. We can discuss in the Innsbruck sprint with the people who are there to see if we can get a rough schedule that works for most.
Calendar planning releases, specially for bugfix ones, i.e. 6.0.x
sounds like a great idea ✨
Knowing that if you make a contribution and gets merged, it will be at most a month away from being in an official release is a great way to encourage upstream contributing 👍🏾
Something like: From 20th to 25th of each month packages are expected to have package releases, from 25th until the end of the month a Plone release with those package releases is to be expected
@mauritsvanrees this idea also sounds great to me! Let's discuss in Innsbruck.
See the release schedule.
Release packages, update versions
bin/manage report --interactive
. This is less needed now that we havemr.roboto
to add packages to the checkouts. Usebin/versioncheck
to see if any new PyPI releases are worth adding, or check the artifact of the versioncheck GitHub Action.checkouts.cfg
.CMFPlone metadata.xml
and latestupgrade step
are in sync, and that they are higher than in the previous Plone release.plone.staticresources
andmockup
. Ask on Discord in the classic-ui or ask Johannes (thet), Peter Mathis (petschki) or Maik (MrTango).plone.restapi
and maybeplone.volto
. If needed, ask the Plone REST api team or Timo (tisto) for a new release.plone.app.locales
. Create an issue there or ask Mikel (erral).plone.app.upgrade
andPlone
yourself.versions.cfg
.Products.CMFPlone
(e.g. 6.0.0a1, later 6.0.0b1 and 6.0.0rc1). Fine to release this on PyPI. Once Plone 6 is final, we can continue doing release candidates for the bugfix releases, so people can try it in a pending release.Release notes, constraints, dist.plone.org
release/6.0-dev
. Most importantly, theauto-checkout
list incheckouts.cfg
should be empty, and theversions.cfg
andrequirements.txt
should be the same. One way that works for me:git checkout release/6.0-dev; git reset --hard 6.0; git reset origin/release/6.0-dev
. Then check which changes you want to commit.6.0-dev
directory on dist.plone.org, and gather files to put there:tox -c release/tox.ini -p auto
to 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. You may want to link to the Zope changelog with a specific tag.release/RELEASE-NOTES.md
. It may be enough to look through the changelog and copy interesting changes.versions.cfg
file and any other versions files from coredev.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 aversions.cfg
file instead.rsync
) these files to the pending release directory. (We used to copy packages as well, but we do not do this for Plone 6 anymore.)Final release, Docker
Products.CMFPlone
to PyPI, updateversions.cfg
.release/6.0-dev
branch update changelog, release notes,constraints.txt
.release/6.0-dev
branch, e.g. 6.0.0a1, and push to GitHub.ln -sfT 6.0.0a1 6.0-latest
#install-and-deploy
Discord channel, that there is a new release. He can create Docker images then.Announcements
You probably want to wait until the Docker images are there, but don't wait long.
plone.securitysupport
,plone.versions
,plone.activemaintenance
. You could ask the security team.