Hi Hanno! Hanno Schlichting wrote:

With the mess of zope/zope.app distributions being part of Zope 2.12, I'd really like to get people away from it and stop maintaining it rather sooner than later. With Plone we are using CMF 2.2 and Zope 2.13 for the upcoming Plone 4.1. With the current roadmap, we'll likely be able to stop using Zope 2.12 in 6-9 months altogether. I think it makes sense to get a new CMF 2.3 in the next couple months as well, so there would be both CMF 2.2 and 2.3 available on Zope 2.13.

Using CMF 2.2 for Plone 4.1 means we have to maintain CMF 2.2 for a long time and Zope 2.12 is the primary platform for CMF 2.2. So if you really want stop maintaining Zope 2.12 soon: Wouldn't it be better to release CMF 2.3 in time for Plone 4.1? Cheers, Yuppie

Hi! Hanno Schlichting wrote:

On Tue, Jan 4, 2011 at 2:53 PM, yuppie<y.2011@wcm-solutions.de> wrote:

...

Using CMF 2.2 for Plone 4.1 means we have to maintain CMF 2.2 for a long time and Zope 2.12 is the primary platform for CMF 2.2. So if you really want stop maintaining Zope 2.12 soon: Wouldn't it be better to release CMF 2.3 in time for Plone 4.1?

Plone 4.1 is long past the implementation deadline for new code. We would have had to have a CMF 2.3 beta release by late October to use it in Plone 4.1.

Off-topic on this list, but for the record: Most CMF 2.3 changes are in code that is not used by Plone. AFAICS the only changes that might affect Plone are the SyndicationTool modifications. But those modifications are anyway not in a releasable state because they cause at least some BBB issues. If that's the reason why Plone 4.1 can't use CMF 2.3, I'd vote for backing out those changes.

But if we get a CMF 2.3 release in the next couple months, we can get it into Plone 4.2, which should be out sometime at the end of this year. In Plone we only support one minor feature release (4.x) at the same time, so as soon as 4.2.0 is released maintenance of 4.0.x and 4.1.x ends.

So what is the plan? Maintenance for Zope 2.12, CMF 2.2 and Plone 4.1 ends simultaneously at the end of this year? Or end Zope 2.12 maintenance earlier and make CMF 2.2 releases for an unmaintained platform? Or drop support for the major target platform between CMF 2.2.x and 2.2.y? Cheers, Yuppie

On Tue, Jan 11, 2011 at 7:58 PM, Charlie Clark <charlie.clark@clark-consulting.eu> wrote:

Am 04.01.2011, 14:25 Uhr, schrieb Hanno Schlichting <hanno@hannosch.eu>:

...

With the current roadmap, we'll likely be able to stop using Zope 2.12 in 6-9 months altogether.

I've given this some thought: as long as Python 2.5 is the default install on Debian-based systems, as it currently is, you can't really go beyond Zope 2.12. This was the reason why support for Python 2.5 wasn't dropped for the ZTK > 1

Python 2.5 isn't supported by Zope 2.12 either (it is by ZTK 1.0 and 1.1). In fact there's no currently supported Zope 2 release that supports Python 2.5 (apart from the volunteer security support for 2.11/2.10 by some community members). And it's not only missing support claims, the code just doesn't work anymore in all cases. In all the hosting environments where we use Debian, we installed backports of Python 2.6. That's the price you pay for using a very stable distro for fast moving web stuff. Hanno

Am 11.01.2011, 22:44 Uhr, schrieb Tres Seaver <tseaver@palladion.com>:

Python 2.5 isn't even getting security fixes from Python devs now, which means that Debian users are holding more risk than they know (I strongly doubt the Debian packagers of Python are up for backporting all the potential security fixes in the 2.6 / 2.7 lines).

I understand that and I don't understand Debian's policy - maybe after they move to a better kernel (no, don't bite...) they'll start following a better release policy as well? But this was precisely the reason cited for keeping support for 2.5 in the ZTK > 1. I find this somewhat contradictory. To the extent that there may well be people out there with existing servers that are dependent upon package management and, therefore, less likely to want to roll their own Python install, this makes sense. So +1 on yuppie's initial suggestion for a 2.12 compatibility marking. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226

On 4 January 2011 17:42, Laurence Rowe <l@lrowe.co.uk> wrote:

On 4 January 2011 13:00, yuppie <y.2011@wcm-solutions.de> wrote:

...

Hi!

Zope trunk (2.14) no longer ships with these Products:

  Products.BTreeFolder2   Products.ExternalMethod   Products.MailHost   Products.MIMETools   Products.PythonScripts   Products.StandardCacheManagers

There are no separate Zope 2.12 compatible eggs for these Products because they are part of the Zope2 2.12.X eggs.

Problem is: Several Products (e.g. CMF) exist that depend on these Products and want to support Zope2 2.12, 2.13 and trunk. But AFAICS there is no way to specify all dependencies correctly in setup.py. As a workaround, CMF currently specifies the 'additional' Zope2 trunk dependencies in buildout.cfg.

If there are no objections or better ideas, I'd like to add a 'zope212_compat' extra to Zope 2.12, 2.13 and trunk. For Zope 2.12 and 2.13 it would be empty, for trunk it would look like this:

    extras_require={       'zope212_compat': [         'Products.BTreeFolder2',         'Products.ExternalMethod',         'Products.MailHost',         'Products.MIMETools',         'Products.PythonScripts',         'Products.StandardCacheManagers',       ],

That would make it possible to specify the Zope2 dependency this way:

    install_requires=[       'Zope2 [zope212_compat] >= 2.12.15',     ]

If Products drop Zope 2.12 support, they can switch to this:

    install_requires=[       'Zope2 >= 2.13.0',       'Products.MailHost', # required Products

You could release empty eggs for those folders. This is the approach we are taking with the separation of Products.CMFPlone from the Plone egg. This allows software to depend on ``Products.CMFPlone`` now but still be compatible with Plone 4.0. See: http://dev.plone.org/plone/browser/Products.CMFPlone/branches/4.0. (A Products.CMFPlone=4.0 pin will be included the versions.cfg for the next 4.0.x release.)

... empty eggs for those /packages/ ... Laurence

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/04/2011 02:24 PM, William Heymann wrote:

On Tuesday 04 January 2011, yuppie wrote:

...

Zope trunk (2.14) no longer ships with these Products:

Products.BTreeFolder2 Products.ExternalMethod Products.MailHost Products.MIMETools Products.PythonScripts Products.StandardCacheManagers

What will this mean for those of us that don't use plone and use all of the above products? Will these products continue to be maintained in some way or are they being abandoned?

If they are being abandoned is there any upgrade path?

They aren't abandoned -- they are being maintained as separately-releasd projects. If your applications depend on one or more of them, you just add them to your 'install_requires' when you port to Zope >= 2.13. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0jhHsACgkQ+gerLs4ltQ6sgQCbBEkstcadqyWV2FkGldvEensh Ni8An0f1JAvZ0ajOLTHhh98lR68c/bA2 =BdNi -----END PGP SIGNATURE-----