Plone 4.3.13 soft-released

Plone 4.3.13 has been soft-released. Please give it a try and let me know if there are any critical issues.

For those who haven't run across soft-releases before, this is the
last step before the final release. Because things haven't been
finalized yet, some packages may change between now and the release. It
is not recommended to use soft-releases in production.

Plone: 4.3.12 → 4.3.13

Products.CMFPlacefulWorkflow: 1.5.14 → 1.5.15
Bug fixes:

- Fixed reinstall.  Deactivating and then activating the add-on
  led to a missing tool and control panel icon.  Another deactivation
  would then fail.  Solution is to mark our base profile as uninstalled
  in the uninstall method.
  This requires ``Products.GenericSetup`` 1.8.1 or higher.
  Fixes `issue 1959 <>`_.

Products.CMFPlone: 4.3.12 → 4.3.13
Bug fixes:

- Fixed ``NotFound`` error when adding controlpanel action through the ZMI.
  See `issue 1959 <>`_.

Products.contentmigration: 2.1.15 → 2.1.16
Bug fixes:

- Fix import location for Products.ATContentTypes.interfaces.

Products.ResourceRegistries: 2.2.12 → 2.2.13
Bug fixes:

- Removed assertion for response status 200 for inline resources.
  If after inlining a ``++resource++`` item the response status was not in the
  200 range, the assertion would fail, leading to the html being returned
  with a wrong mimetype showing raw html and an error while rendering
  Changed it into a condition instead: only restore original headers when
  the status is in 200.

Products.TinyMCE: 1.3.25 → 1.3.26
New features:

- Crop description text in link dialog to 60 chars
  (less json data to transmit for folders containing a lot of articles)

- Show path in alt-text of articles too (to distinguish Items having the
  same title) [fRiSi]

archetypes.referencebrowserwidget: 2.5.8 → 2.5.9
Bug fixes:

- Fix import location for Products.ATContentTypes.interfaces.

archetypes.schemaextender: 2.1.6 → 2.1.7
Bug fixes:

- Update docs about ``Products.ATContentTypes.interfaces`` import location.

- Fix imports from Globals that was removed in Zope4
  [pbauer] 1.9.0 → 1.9.1
Bug fixes:

- Updated jquery.form and to latest versions.
  [msom] 1.5.8 → 1.5.10
Bug fixes:

- Rerelease, because one buildout somehow cannot find 1.5.9.

- Don't check if dexterity is present by importing from plone.directives, grok
  is no longer part of dexterity.
  [fredvd] 4.3.12 → 4.3.13
- Update the Transifex resourceas configuration at Transifex project

- Update Spanish translations.

- Update Traditional Chinese translation.
  [l34marr] 1.2.4 → 1.2.5
New features:

- Add support for *have* and *have-not* import conditions in

- Add support for optional condition attribute in registry.xml entries
  to allow conditional importing of records. Conditions themselves are
  not import (nor exported).

plone.behavior: 1.1.4 → 1.2.0
New features:

- For zcml registration:
  If both, no ``for`` and no ``@adapter`` is given,
  fall first back to ``marker`` if given (new),
  else to ``Interface`` (as it was already before).

Bug fixes:

- Cleanup: Make Jenkins CI code analysis silent by fixing the issues.

plone.testing: 4.1.1 → 4.1.2
- Replace `ZServer.PubCore` handler with a threadless version, which fixes
  `coverage` reporting.  See

z3c.formwidget.query: 0.12 → 0.13
- Compatible with z3c.form > 3.2.10, where radio and checkbox `items` property is a generator.

Products.LinguaPlone: 4.1.8 → 4.2
New features:

- Show the native language name on the "Translate into..." menu

Bug fixes:

- Fix import location for Products.ATContentTypes.interfaces.

- Don't fail while uninstalling, if LinguaPlone is already uninstalled.

I pointed to the pending release in buildout.plonetest so new test builds will use it:

This way will be easier to catch errors early.

@esteele I can confirm we are experiencing the same issues with default values on z3c.form-based schemas as in Plone 4.3.12:

I tried 4.3.13-pending on one site and found no problems.

Well, one problem: inline validation does not work. But I see this was already wrong in 4.3.12. I created for that.

We don't know if this is the best approach @hvelarde. for example is broken, so everyone that uses will have a broken build if the job is run before you edit this line to remove the pending url when it's gone.

Also, when using plone-4.3.x.cfg I think people expect a 4.3.x generic line, being x the last valid one, and not a specific release like 4.3.13-pending that needs to be edited for every new release.

We would need something like to avoid that, but I don't know if you like this idea or even if it's feasible. We do agree in testing against -pending releases though.

yes, I know; my first plan was to create that additional file but then I realized that it makes no sense because the pending releases are there for a very limited period of time before being final.

I would like to have a way to use this pending release on all of our test just to make sure the early release is good enough to be finally released; this is to avoid situations like the one we are currently facing with Plone 4.3.12.

most of the people only test migration steps and browsing, but probably then don't test content editing until is too late to roll back.

I think is not that bad that a build is broken because we're testing against a pending release; I even think is better to have people screaming earlier.

anyway I'm open to other ideas.

Yes. We agree that testing against -pending should be done and gave the suggestion. @esteele is it possible/feasible? To have an url that always points to the last pending release?

The problem with what you're doing @hvelarde is that you'll be responsible for changing this url for every new release (and pending) and a broken build may happen not because an error was found but because the temporary -pending url is now gone, being "A boy who screamed wolf" situation. It may be rare, but it may happen. But if you think it's better to have this kind of error in favor of the advantage of catching errors in pending releases earlier, we'll leave it up to you. Thanks for thinking about this and let's see what others think.

The more testing the better, so whatever I can do to promote that...

What happens to 4.3-latest-pending when the release is made final?

What happens to 4.3-latest-pending when the release is made final?

Indeed, we don't have an answer for that. Thinking a little bit more, this url is not needed since the intended behavior would be the same as using directly: this file will always have pins that will be in a future release. Not strictly and tied specifcally to a numbered release, but... @hvelarde FYI.

I think the plone-x.x.x.cfg files should always point to the latest release and a pending release is the latest release of a branch.

yes we'll have to edit the file, but we already do so; I don't think that's a problem.

What happens to 4.3-latest-pending when the release is made final?

What about this suggestion: this file will always have the last pending release created by @esteele. This file is never deleted, so @hvelarde don't need to change plone-x.x.x.cfg file, since will always exist.

Since this file is never deleted, 4.3-latest-pending, after being validated, will have the same contents as 4.3.13.cfg. When a new release is made (4.3.14-pending for example), will have the pin for this new release: this way you're always validating the latest release and the pending release, when available, and don't need to change the plone-x.x.x.cfg file.

@hvelarde if following this approach, it would be a good idea to document this approach inside plone-x.x.x.cfg nexto to pending url.

My fix for the inline validation bug introduced in 4.3.12 was merged to CMFPlone:

the issue, is that somebody will have to edit the file anyway; so it really don't matter to me if me (or you) point it to the pending release and then to the final release when available.

adding a new configuration will make us change all current add-ons and point them to the new location, which is not a good idea.

awesome! I'll test it now.

adding a new configuration will make us change all current add-ons and point them to the new location, which is not a good idea.

People will still point to plone-x.x.x.cfg file, that itself points to, that you'll never need to change since it's always the last pending release or the last release. All add-ons won't have to point to a new location, I think you misunderstood the idea.

This is not a new configuration, is the same configuration but with an url that doesn't need to change for every new pending release / full release.

I'll let @esteele decide; I don't want to make his life more complicated.

Agreed. This is just a suggestion that we don't even know if it's feasible from a release manager perspective.

But most importat is, did you get the idea? If this doesn't show as a complicated setup for @esteele, do you think it's better than changing number for every new release in buildout.plonetest?

I've cut a new release of CMFPlone to include Maurits' fixes. Because of that, I've had to bump the release version, so the new cfg is at

I have updated buildout.plonetest according this:

here's another blocker:

tests in collective.cover are failing now.

I tested 4.3.14-pending in three sites and all seems well.

I wouldn't call the problem a blocker: there is only a problem in tests, and then only for some add-ons, and the problem is already there in 4.3.12 IIUC.
It should be fixed of course, but it's not a blocker in my definition.

I'm ok with that as long as the fix is made available immediately after the release.

currently we've been forced to test against Plone 4.3.11 and plone.api 1.6 and that's far from ideal.

notice that our test setup is good enough to help you discover 2 bugs (HT @idgserpro).