Plone 6.0.0b3 released

[mauritsvanrees]

The third beta is here! Some links:

• You can use the plone-backend docker image .
• With Buildout you can use the versions file at https://dist.plone.org/release/6.0.0b3/versions.cfg. On top of that, you may want to extend versions-extra.cfg and versions-ecosystem.cfg.
• With pip you can use the constraints file at https://dist.plone.org/release/6.0.0b3/constraints.txt
• Here is the release page on plone.org.

Release notes for Plone 6.0.0b3

Released: Tuesday October 4, 2022.

Highlights

Major changes since 6.0.0b2:

• Products.PlonePAS: Increase the minimum password length to 8 characters.

• pip: We have actually downgraded pip because version 22.2 and higher have an incompatibility with Buildout. Buildout works, but it cannot read the information about which Python versions are required for a package. If you do not use Buildout, feel free to use the latest pip version.

• plone.restapi:

  • Add @userschema endpoint for getting the user schema.

  • Add @transactions endpoint to fetch transactions that have been made through the Plone website.

  • Added @aliases endpoint with GET/POST/DELETE.

  • Improve performance of serializing image scales.

• TinyMCE rich text editor updates in various packages:

  • Disable advlist plugin by default, it produces unclean inline styles.

  • Add inserttable to toolbar.

  • Add and improve table styles.

  • Add UI styles in non-inline mode.

  • Actually load theme-specified styles CSS in TinyMCE.

• plone.staticresources:

  • Use successor repository of svg-country-flags.

  • Upgrade to Bootstrap 5.2.2.

  • Upgrade to Mockup 5.0.0-alpha.24.

• plonetheme.barceloneta:

  • Bootstrap 5.2.2

• plone.app.layout: Use a variable to allow customization of the image scale used for social tags

Volto frontend

The default frontend for Plone 6 is Volto. Latest release is 16.0.0-alpha.40.
See the changelog.

Python compatibility

This release supports Python 3.8, 3.9, and 3.10.

Installation

For installation instructions, see the documentation.
This documentation is under development, but this should get you up and running. No worries.

Help wanted

We should have a release candidate shortly after the conference. Some are even hoping that this could be done during the conference live on the podium. At any rate, Plone 6 final needs you, the community! Wondering how you can help?

• Here is a list of issues marked as blocker. Currently only three. See if you can help there. Or see if there are issues that should be added to this list.
• You can work on documentation. Create new content, edit content, read and review content.
• You can add translations.
• Here is the project board Plone 6.0 - tasks to final. Some may need to be on the first list.
• CMFPlone has a milestone Plone 6.0 with yet other tasks. We seem to like lists of tasks.

[alert (Alessandro Pisa)]

Nice work!
About the multiple versions file, I was thinking about having a versions-combined.cfg that sums up all of the three?
I do not know if that has more drawbacks that advantages.

[mauritsvanrees]

I am not completely happy with the current way. It is not so nice that in 5.2 the versions.cfg gets you everything, and in 6.0 you only get the core versions. In this late beta stage I don't want to change much, but on the other hand it is not nice to have to support a suboptimal solution for years.

A versions-combined.cfg could be an option, indeed. Should be fairly straight forward to generate a full list of all versions during the release. Or are you thinking of a small file that simply extends the others? That could work too.

I am also thinking about having a versions-plone-core.cfg that really only contains Plone and its dependencies, probably not even extending the Zope versions files. Especially I think this should not contain zc.buildout, pip, setuptools: we leave that up to whatever the user is comfortable with. Currently we force a slightly older pip because buildout has a problem with the latest versions. We would avoid that.

The danger is that, combined with the Zope files, we end up with ten versions files and no one has any idea where a package pin should be.

[alert (Alessandro Pisa)]

I see your points and I do not really have a preference

I agree about not to pinning buildout and setuptools (they are pinned already by requirements).

Almost all my buildout versions start with:

[versions]
# Use the ones from the requirements
zc.buildout=
setuptools=
pip =
wheel =

[erral (Mikel Larreategi)]

In the past (specially in Plone 4 buildouts) we have found very risky to have unpinned zc.buildout and setuptools versions in buildout.cfg. We have often found buildout running in a loop constantly updating zc.buildout and setuptools versions because of this.

Nowadays we always pin the versions of those products in buildout and their versions match the ones in requirements.txt even when we have to run old Plone 4 buildouts. We want to avoid fighting setuptools and buildout versions.

[alert (Alessandro Pisa)]

I had the buildout loop for the opposite reason...

So far creating the virtualenv like this:

python3 -m venv py3
./py3/bin/pip3 uninstall -y setuptools
./py3/bin/pip3 install -IUr requirements.txt
./py3/bin/pip3 install -r https://dist.plone.org/release/$VERSION/requirements.txt

and unpinning that stuff never failed.

[mauritsvanrees]

I had both problems. Sometimes a buildout error was fixed by adding a pin for zc.buildout/setuptools, sometimes it was fixed by removing those pins. Probably the [buildout] newest = true/false setting influences this. My approach is always to keep requirements.txt and versions.cfg in sync for zc.buildout, setuptools, and maybe pip.