Plone 5.1.3 - include more bug fixes?

Development
1

Hi,
Plone 5.1.3 is pending, but there are several important fixes it would be super to include:



(I can refactor #168 to include a 5.1.2->5.1.3 step)


(I can refactor 170 to include a 5.1.2->5.1.3 step)

Is it possible to repack - or should we make a small bugfix 5.1.4 release very quickly after 5.1.3?

Sune

3 Likes
2

This regression should also be a candidate: https://github.com/plone/Products.CMFPlone/issues/2468
Here is a PR https://github.com/plone/plone.app.content/pull/160 but I most likely don't have time to polish it for mergability.

3

@tomgross I can take a look at it

4

And another one: https://github.com/plone/Products.CMFPlone/issues/2463

1 Like
5

PRs for that one are merged but not released:

6

Also: https://github.com/plone/Products.CMFPlone/issues/2512

7

How about skipping the broken 5.1.3 and release a new 5.1.4 with all the bugfixes available. @esteele what do you think?

8

That's my plan. We quickly got past what I can conceivably stuff into a 5.1.3.1 release.

1 Like
9

sounds good to me:)
Let me know what I can do.

On my list so far is:
rebase on 1.5.x


Ready to merge:


10

Now ready to merge:

12

Unfortunately the opposite is also true, there are also some problems in plone.app.contenttypes that would go into a release at the moment if it is released and included:

This improvement/fix in plone.app.contenttypes breaks a default and custom mosaic templates in plone.app.mosaic:


Layouts and default_pages are not correctly migrated in plone.app.contenttypes, existing issue but could have more impact after another fix done in march:


Link CT links with navigationroot variable substitution are broken when the site is accessed through VHM after a fix to support urlparams in the link.


13

A:

This is introduced in 1.4.12.dev (HEAD)

B: "Layouts and default_pages are not correctly migrated"
The march commit is already part of plone 5.1.2 (p.a.contenttypes 1.4.10)
So making a CMFPlone release using 1.4.11 would not change anything (would not make the situation worse)

C: Link CT broken:
Is broken in 5.1.2 (p.a.contenttypes 1.4.10) so making a CMFPlone release using 1.4.11 would not make the situation worse.

Conclusion:
If we use the already released 1.4.11 of p.a.contenttypes we do not make the situation worse.
If we release and include 1.4.12 we do make the situation worse.

Of course unless we can fix these three issues - but I suspect it could take time.

1 Like
14

@sunew I fully agree, I meant with "if it released" a new release of plone.app.contenttypes, not Plone itself.

15

@fredvd I know :slight_smile: It was super valuable input - important to know.

16

Current status of all PR's (+ related) mentioned in this thread:

merged:

working on this:

2 Likes
17

@fredvd
A) What would it take to get these fixed?


A migration step in mosaic?

B) This one could be merged I guess:

C) What would this one take - is the fix mentioned by @claytonc the solution?


https://github.com/plone/plone.app.contenttypes/issues/457 (fixing 466 would close this?)

18

A) I have no idea. A migration would fix shared layouts, but not layouts stored on filesystem in add'ons. After this issue I learned out that mosaic layouts are non trivial and broekn anyway as soon as you use anything 'non' transient in p.a.mosaic 2, so I'm not sure if this really is a 'big' issue, but it's still annoying and might be a red flag for more knowledgable developers where the Marker Interface clean up/fixes might cause problems, I don't know.

B) has been merged.

C) IMHO root cause for https://github.com/plone/plone.app.contenttypes/issues/466 is the change/fix done for https://github.com/plone/plone.app.contenttypes/issues/457 .

19

Please consider this too: https://github.com/plone/plone.app.multilingual/pull/323

1 Like
20

has just been merged by Jensens :slight_smile:

21

I'm working on getting packages released this week, so get your PRs in! If we wait too long, the sprinters are going to make my life miserable next week. :stuck_out_tongue:

1 Like