Task #2955
closed
Run Plone Buildout On LibO Extensions
Added by Andreas Mantke over 5 years ago.
Updated over 4 years ago.
Description
The LibO Extensions Site uses not current versions of the Plone add-ons and also not current Plone versions. The current version of Plone 5.0 is 5.0.10 (last bugfix release of that series). Old stable is 5.1.5 yet. But during the next 3.5 month it needs an update to 5.2 (before 1.1.2020).
Thanks for the preemptive warning Andreas, but I'm wondering about the deadline and urgency here: https://plone.org/security/hotfixes suggests that 5.0.8 is still seeing security support, and thankfully you applied the last hotfix in late 2017. Skimming over the changelog for following releases in 5.0 I see nothing obviously security related indeed. Many of the services (both frontend as well as lower down the stack) we're running aren't the latest upstream version or the most recent version in an LTS branch. As long as they receive security support, either from upstream or from the OS vendor, there is no real urgency to upgrade, at least not as far as the infra team is concerned. FWIW preferring targeting fixes over upgrade to a point release is also the model used by our OS vendor for most software.
The 5.0.10 has some bugfixes, but is the last release of that series. Currently the focus is on 5.1 and 5.2. Deadline for 5.2 with a necessary intermediate step of 5.1 will be 31.12.2019.
- Assignee changed from Florian Effenberger to Guilhem Moulin
You mean 2019-12-31 is the date after which 5.0.8 (or ≥5.0.10) will cease receiving security support from upstream? If this is about Python2, please note while it'll be EOL in 2020, it's still tied to many distros, the LTS team of which have committed to keep supporting until the distro itself is EOL'ed. It was the same thing with PHP.
I strongly disagree with the assessed severity if it's about upgrading software that still receives security support; of course, if I don't read https://plone.org/security/hotfixes right then it's another story…
(Also, reassigning this to me because as it's task for the infra team. Florian Effenberger would most likely have forwarded it to me anyway.)
By the way in tdf.templateuploadcenter/tdf/templateuploadcenter/notifications.py#L12 resp.
tdf.extensionuploadcenter/tdf/extensionuploadcenter/notifications.py#L12 I suppose that tempprojectcontact and extprojectcontact should respectively be tempprojectemail and extprojectemail (or projectcontact) to match the index name, no?
Otherwise AFAICT (not tested) notifiyAboutNewVersion() will crash, either because catalog.uniqueValuesFor() doesn't know about the index, or because it returns a non-iterable object.
Given there are no other occurrences of {temp,ext}projectcontact I guess these are typos.
Thanks for the hint. I fixed it and published a new release.
The mail suffixes should be email no? AFAICT there is no index named extprojectmail nor tempprojectmail.
It seemed I need some New blasses ;-)
I overlooked the little e. Will fix that soon.
The latest fix is in Github already available.
- Status changed from New to Closed
Closing: no longer relevant after the migration.
Also available in: Atom
PDF