-
-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Latest alpha release is not working with Plone 5.2.6 - plone.restapi 7.5.0 #22
Comments
@avoinea how were you able to run buildout with plone.volto latest? Since 3.1.0a5: https://github.com/plone/plone.volto/blob/main/CHANGES.rst#310a5-2021-11-07 plone.volto requires at least plone.restapi 8.13.0: https://github.com/plone/plone.volto/blob/main/setup.py#L59 That ships with the IJSONSummarySerializerMetadata serializer: So you either have to downgrade to plone.volto 3.0.x or backport the plone.restapi PR. |
@tisto plone.restapi 7.5.0 is pinned here https://dist.plone.org/release/5.2.6/constraints.txt Maybe we should also pin plone.volto to |
Otherwise the plone/plone-backend Docker images 5.2.6 - python 3.7 and 3.8 are broken: https://github.com/plone/plone-backend/actions/runs/1441266348 |
It also breaks plone/setup-plone@v1.0.0 actions. |
For Docker images I pinned it to 3.1.0a4 https://github.com/plone/plone-backend/actions/runs/1444457283 But I still think it should be explicitly added to https://dist.plone.org/release/5.2.6/constraints.txt as we already have it for 6.0 https://dist.plone.org/release/6.0.0a1/constraints.txt |
Released plone/setup-plone@v1.1.0 that supports pinning of versions (or installing new eggs) |
Is action still needed here? |
@mauritsvanrees plone.volto is supposed to work with both Plone 5.2 and Plone 6 and we plan to support Plone 5.2 for a while. At least as long as Plone 6 did not see a final release. |
Does it really help to pin an older Alpha release of plone.volto in 5.2? |
Ok, so here is what happens: plone.volto 3.1.0a5 requires the new JSONSummarySerializerMetadata: https://github.com/plone/plone.volto/blob/main/CHANGES.rst#310a5-2021-11-07 This serializer has been added to plone.restapi 8.13.0: https://github.com/plone/plone.restapi/blob/master/CHANGES.rst#8130-2021-11-05 Plone 5 ships with plone.restapi 7, which does not have this serializer. We can not ship with plone.restapi 8 because it dropped Python 2 support. The easiest way out would be to pin plone.restapi to 8.13.0 and mark this ticket as wontfix. In theory, there are other options: a) make Plone 5 use the latest plone.restapi 8 branch in version pins b) backport that serializer to plone.restapi 7 and upgrade the Plone 5 version pins to use the latest plone.restapi 7 release Option a) is not possible because plone.restapi 8 dropped Python 2 support. We can not drop Python 2 support for Plone 5. Option b) means we will have to support four different frontend stacks (in the long run): a) Plone 4 / plone.restapi 7 / Volto XX? (used by EEA) b) Plone 5.2 / plone.restapi 7 / Volto 14 (meh) c) Plone 5.2 / plone.restapi 8 / Volto 14 (used by most Volto core devs) d) Plone 6 / plone.restapi 8 / Volto 14 (future stack) The Plone 6 frontend stack is a complex beast (from a release management point of view). The situation is comparable to what we had when we tried to support Dexterity for Plone 3. This was hellish and we have to clearly say what we plan to support and whatnot. As soon as Plone 6 final is out, we just can not do things like this any longer. IMHO we can only support the latest stack of plone.restapi (8.x), plone.volto (3.x), and Volto (14.x + X) in Plone 5.2 and Plone 6. I do not plan to cut any "Plone 6 only" releases in the near future for this stack, so things will stay for a while. Anything else will require lots of work and cause tons of problems in the future. I am happy to make sure that a modern Volto stack works on both Plone 5.2 and Plone 6 for quite some time. Though, for anything else, people are on their own (at least as long as nobody steps up who is willing to officially support those use cases, this is open source after all :)). |
How about pinning I feels a bit strange to have a core package pinned to two different versions, but it may make sense in this case. |
This may need plone/plone.restapi#1194 |
@mauritsvanrees right, I did not think about that option. You are the release manager, if you are fine with two different version pins in Plone 5.2 I'd be ok as well. :) |
This means two different branches in sources.cfg. That will be confusing when testing a PR... See discussion in plone/plone.volto#22
This means two different branches in sources.cfg. That will be confusing when testing a PR... See discussion in plone/plone.volto#22
I have created a PR on coredev to do that: plone/buildout.coredev#754 I realize a problem though: it is not only a different version, but also a different branch in sources. That makes it impractical to test |
Maybe playing with |
I already did that on the coredev PR, and it works for normal use. But |
The text was updated successfully, but these errors were encountered: