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 <https://github.com/plone/Products.CMFPlone/issues/1959>`_.
[maurits]
Products.CMFPlone: 4.3.12 → 4.3.13
----------------------------------
Bug fixes:
- Fixed ``NotFound`` error when adding controlpanel action through the ZMI.
See `issue 1959 <https://github.com/plone/Products.CMFPlone/issues/1959>`_.
[maurits]
Products.contentmigration: 2.1.15 → 2.1.16
------------------------------------------
Bug fixes:
- Fix import location for Products.ATContentTypes.interfaces.
[thet]
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
``plone.resourceregistries``.
Changed it into a condition instead: only restore original headers when
the status is in 200.
[maurits]
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)
[fRiSi]
- 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.
[thet]
archetypes.schemaextender: 2.1.6 → 2.1.7
----------------------------------------
Bug fixes:
- Update docs about ``Products.ATContentTypes.interfaces`` import location.
[thet]
- Fix imports from Globals that was removed in Zope4
[pbauer]
plone.app.jquerytools: 1.9.0 → 1.9.1
------------------------------------
Bug fixes:
- Updated jquery.form and jquery.tools to latest versions.
[msom]
plone.app.linkintegrity: 1.5.8 → 1.5.10
---------------------------------------
Bug fixes:
- Rerelease, because one buildout somehow cannot find 1.5.9.
[maurits]
- Don't check if dexterity is present by importing from plone.directives, grok
is no longer part of dexterity.
[fredvd]
plone.app.locales: 4.3.12 → 4.3.13
----------------------------------
- Update the Transifex resourceas configuration at Transifex project
https://www.transifex.com/plone/plone4/
[macagua]
- Update Spanish translations.
[macagua]
- Update Traditional Chinese translation.
[l34marr]
plone.app.registry: 1.2.4 → 1.2.5
---------------------------------
New features:
- Add support for *have* and *have-not* import conditions in
registry.xml
[datakurre]
- Add support for optional condition attribute in registry.xml entries
to allow conditional importing of records. Conditions themselves are
not import (nor exported).
[datakurre]
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).
[jensens]
Bug fixes:
- Cleanup: Make Jenkins CI code analysis silent by fixing the issues.
[jensens]
plone.testing: 4.1.1 → 4.1.2
----------------------------
- Replace `ZServer.PubCore` handler with a threadless version, which fixes
`coverage` reporting. See https://bitbucket.org/ned/coveragepy/issues/244.
[witsch]
z3c.formwidget.query: 0.12 → 0.13
---------------------------------
- Compatible with z3c.form > 3.2.10, where radio and checkbox `items` property is a generator.
[thomasdesvenain]
Products.LinguaPlone: 4.1.8 → 4.2
---------------------------------
New features:
- Show the native language name on the "Translate into..." menu
[erral]
Bug fixes:
- Fix import location for Products.ATContentTypes.interfaces.
[thet]
- Don't fail while uninstalling, if LinguaPlone is already uninstalled.
[thet]
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 http://dist.plone.org/release/4.3-latest-pending/ 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.
Yes. We agree that testing against -pending should be done and gave the http://dist.plone.org/release/4.3-latest-pending/ 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.
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 https://raw.githubusercontent.com/plone/buildout.coredev/4.3/versions.cfg 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.
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), http://dist.plone.org/release/4.3-latest-pending/ 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.
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.
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 http://dist.plone.org/release/4.3-latest-pending/, 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.
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 tested 4.3.14-pending in three sites and all seems well.
I wouldn't call the plone.app.testing 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.