How to install!
Fassembler profiles are available at https://svn.openplans.org/svn/build/requirements/opencore-maximal/tags/opencore-0.18.1 (for a full stack build) and https://svn.openplans.org/svn/build/requirements/opencore-minimal/tags/opencore-0.18.1 (for a minimal build of just Zope)
If you are upgrading an existing build, it is possible to do it in place. Just point your opencore code to https://svn.openplans.org/svn/opencore/tags/0.18.1/ and restart Zope. But note two additional details:
- You will likely want to point your Products.listen code (in the opencore-bundle directory) to https://svn.plone.org/svn/collective/Products.listen/tags/0.6.4/ which contains a number of fixes for non-ASCII characters.
- If you are using Twirlip, you should also point your Twirlip code to https://svn.openplans.org/svn/Twirlip/tags/0.6/ and restart the Twirlip paster process.
What’s in this release
The 0.18.1 release is a bugfix release with no new dependencies or data migrations required. It addresses several bugs involving non-ASCII characters; several typos in the default templates and translations; and a long-standing bug (#2896) with the Ajax validation on the account creation form.
It also contains a few improvements to the user interface, including:
- Moved “watch/unwatch” control (if you are using Twirlip) on wiki pages to the RHS tabs alongside view/edit/history to take up less screen space and keep all page-level controls in one place.
- Add “promote to admin” and “demote from admin” buttons on @@manage-team for project admins to change other members’ roles. This functionality already existed, but only with hidden AJAX dropdowns that users didn’t notice. (The hidden AJAX dropdowns are still there.)
And, also, this release contains some new hooks for plugins to extend and customizize an OpenCore instance.
The complete list of changes can be found at https://svn.openplans.org/svn/opencore/tags/0.18.1/changes/0.18.1
Wait a minute, I thought this was a bugfix release!
I’m being a bit flexible by introducing new extension hooks in a bugfix release; strictly speaking these should wait for the next feature release, so that we don’t start having plugins that depend on a bugfix release or higher. If we were maintaining multiple parallel release branches and backporting bugfixes to an earlier release this would get confusing fast.
However, since no backports are being made to the 0.17 branch, and since the code tagged as 0.18.1 has been running in production (on Coactivate.org) smoothly for several weeks, I am not expecting any ongoing development to any release’s branch other than trunk/0.19. And because these are all very localized changes that do not break any existing tests and should not introduce any new bugs, I felt it was more important to get them into this release than to wait for the 0.19 release, which will include significant new features as well.
After opencore reaches version 1.0 I’ll be much more strict about how bugfix releases are defined. Until then I think having a bit of room for flexibility is more important.
Note that the IRC channel has changed from #openplans to #opencore