Hi there, we had an initial roadmap discussion back in March (https://mail.zope.org/pipermail/zope-dev/2010-March/039915.html). Some things have changed since then, so it's time for an update. The big picture: Zope 2.12.0 final was released October 1, 2009 - the first alpha back in February 2009. A lot of time has passed since then and we have made quite a number of changes to Zope2 in the meantime. Plone 4.0 is getting ever more delayed and is still in late beta. Based on the current speed it will be another two years until there's a final 5.0 release of Plone. This is far too long for not having a Zope 2 release. So I talked to Eric Steele as the Plone 4.x release manager and a couple of people in the community. There is general agreement that updating to a Zope 2.13 release for Plone 4.1 is a sensible approach. Plone 4.1 has an approximate release of sometime in six to nine months. The plan: Aim for having a Zope 2.13 release in time for Plone 4.1, get a first alpha release out by the end of the month or early July. We can have more alpha releases during the summer, a beta probably around the zope-dev summit / German Zope User Group conference in early September. What do we have in Zope 2.13: - zope.app removal - moving formlib out of the core into five.formlib - WSGI - thx to Tres and some help from the Plone Symposium East sprint, we have native WSGI support in Zope 2 now. Probably can use some polishing, more testing and documentation - perfect tasks for alpha releases and larger community involvement. - ZTK - The ZTK release team is getting close to having a first ZTK 1.0 alpha release out. I'm confident Zope 2.13 can be based on an official ZTK release. - Five deprecation - I did a whole bunch of work here and I consider it good enough for a next step. There's always more to do, but there's enough already in this release. - Reduce C code in Zope 2 - I made good progress on this. AccessControl has almost no Zope2 dependencies anymore and DocumentTemplate is cleaned up. Some more work can be done during the alpha releases and we can probably finish this one. - ZODB 3.10 - Current Zope 2 trunk is already using a 3.10 beta release. I talked to Jim and he's confident to get a final release out in a matter of two to three months or so. That's quite a bit already. Support for Python 2.7 is blocking on the RestrictedPython security review for the most part, Python 3 support is not on the radar. I hope we get some more changes from Martin Aspeli's work on plone.(app.)testing and a new more modular testing infrastructure. There's a bunch of stuff in the startup process and ZCML loading that can be cleaned up. In order to make this story more appealing, I spent the last two weekends on cleaning up CMF and Plone and making it compatible with current Zope trunk. As of this moment all tests of CMF and Plone pass on Zope trunk. The changes are minimal and backwards compatible, so they are also in the stable releases. This means both CMF 2.2.1 and Plone 4.0 beta5 are going to be fully compatible with Zope trunk. Comments, suggestions, more work you'd like to get into 2.13? Cheers, Hanno
hey, On 12/06/2010 Hanno Schlichting wrote:
What do we have in Zope 2.13:
[...]
Comments, suggestions, more work you'd like to get into 2.13?
another build system would be magnificent :-) the new build system in zope2.12 makes it hard/impossible to distribute zope2 binaries within linux/*bsd/hurd/... distributions. so far no distribution i know contains zope2.12, and the most obvious reason is the new build system. thus i suggest to either provide monolithic tarballs which do contain the debendencies, or change release policy for the dependencies to not break backwards compability with every minor release. greetings, jonas
On Sat, Jun 12, 2010 at 10:45 PM, Jonas Meurer <jonas@freesources.org> wrote:
another build system would be magnificent :-)
the new build system in zope2.12 makes it hard/impossible to distribute zope2 binaries within linux/*bsd/hurd/... distributions. so far no distribution i know contains zope2.12, and the most obvious reason is the new build system.
In the Zope community we have decided to stop maintaining our own build infrastructure, as we simply do not have the resources to do so. Getting this right in a cross platform manner including Windows is no small task and there's no general open-source build infrastructure that provides this. Therefor we have decided to go with a language specific build infrastructure in the form of distutils and its extension setuptools / distribute. Personally I think this has been the right choice for us and has triggered a new interest in distutils. distutils2 is the latest offspring of that effort and is making good progress. Better integration into operating system package managers is one of the main focus areas of that effort. While solving these issues on the Python language level takes more time, it ultimately is the better approach.
thus i suggest to either provide monolithic tarballs which do contain the debendencies, or change release policy for the dependencies to not break backwards compability with every minor release.
I consider packaging up individual Python distributions as individual system packages as a flawed approach. The specific dependencies on exact versions of these distributions for any given application are too diverse for this approach to make much sense. The number of releases is so frequent and the stability requirements so different from system packages, that this just isn't a good match. If I were to package anything as a system package, then it would be one big package for something like CMFDefault, Plone or Zenoss as an application or one package for a custom developed application. zc.sourcerelease is one approach to help in this task for a zc.buildout based application. Hanno
hello, On 13/06/2010 Hanno Schlichting wrote:
On Sat, Jun 12, 2010 at 10:45 PM, Jonas Meurer <jonas@freesources.org> wrote:
another build system would be magnificent :-)
the new build system in zope2.12 makes it hard/impossible to distribute zope2 binaries within linux/*bsd/hurd/... distributions. so far no distribution i know contains zope2.12, and the most obvious reason is the new build system.
In the Zope community we have decided to stop maintaining our own build infrastructure, as we simply do not have the resources to do so. Getting this right in a cross platform manner including Windows is no small task and there's no general open-source build infrastructure that provides this. Therefor we have decided to go with a language specific build infrastructure in the form of distutils and its extension setuptools / distribute.
Personally I think this has been the right choice for us and has triggered a new interest in distutils. distutils2 is the latest offspring of that effort and is making good progress. Better integration into operating system package managers is one of the main focus areas of that effort. While solving these issues on the Python language level takes more time, it ultimately is the better approach.
thus i suggest to either provide monolithic tarballs which do contain the debendencies, or change release policy for the dependencies to not break backwards compability with every minor release.
I consider packaging up individual Python distributions as individual system packages as a flawed approach. The specific dependencies on exact versions of these distributions for any given application are too diverse for this approach to make much sense. The number of releases is so frequent and the stability requirements so different from system packages, that this just isn't a good match.
If I were to package anything as a system package, then it would be one big package for something like CMFDefault, Plone or Zenoss as an application or one package for a custom developed application. zc.sourcerelease is one approach to help in this task for a zc.buildout based application.
first, thanks for clarifying. did i get you right, that for the future, monolithic source releases of zope2 are planned again once the dust has settled? and second, does documentation exist which explains how to craft a monolithic tarball with zc.sourcerelease in order to build zope2.12 without network access? i still didn't get the picture regarding buildout, and thus don't understand zc.sourcerelease either :-/ greetings, jonas
Hi. On Mon, Jun 14, 2010 at 4:16 PM, Jonas Meurer <jonas@freesources.org> wrote:
first, thanks for clarifying. did i get you right, that for the future, monolithic source releases of zope2 are planned again once the dust has settled?
No. There is currently no monolithic released planned at all. Only if someone does all the work of automating such a release, engage with the community to discuss the approach and is willing to adjust to community feedback, only then I as the release manager might make those steps part of the release process. I'm not aware of anyone who has shown even remote interest in this task.
and second, does documentation exist which explains how to craft a monolithic tarball with zc.sourcerelease in order to build zope2.12 without network access? i still didn't get the picture regarding buildout, and thus don't understand zc.sourcerelease either :-/
I'm not aware of any specific documentation. www.buildout.org and the distutils-sig mailing list [1] would be the appropriate places to look. Hanno [1] http://mail.python.org/mailman/listinfo/distutils-sig
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonas Meurer wrote:
hello,
On 13/06/2010 Hanno Schlichting wrote:
On Sat, Jun 12, 2010 at 10:45 PM, Jonas Meurer <jonas@freesources.org> wrote:
another build system would be magnificent :-)
the new build system in zope2.12 makes it hard/impossible to distribute zope2 binaries within linux/*bsd/hurd/... distributions. so far no distribution i know contains zope2.12, and the most obvious reason is the new build system. In the Zope community we have decided to stop maintaining our own build infrastructure, as we simply do not have the resources to do so. Getting this right in a cross platform manner including Windows is no small task and there's no general open-source build infrastructure that provides this. Therefor we have decided to go with a language specific build infrastructure in the form of distutils and its extension setuptools / distribute.
Personally I think this has been the right choice for us and has triggered a new interest in distutils. distutils2 is the latest offspring of that effort and is making good progress. Better integration into operating system package managers is one of the main focus areas of that effort. While solving these issues on the Python language level takes more time, it ultimately is the better approach.
thus i suggest to either provide monolithic tarballs which do contain the debendencies, or change release policy for the dependencies to not break backwards compability with every minor release. I consider packaging up individual Python distributions as individual system packages as a flawed approach. The specific dependencies on exact versions of these distributions for any given application are too diverse for this approach to make much sense. The number of releases is so frequent and the stability requirements so different from system packages, that this just isn't a good match.
If I were to package anything as a system package, then it would be one big package for something like CMFDefault, Plone or Zenoss as an application or one package for a custom developed application. zc.sourcerelease is one approach to help in this task for a zc.buildout based application.
first, thanks for clarifying. did i get you right, that for the future, monolithic source releases of zope2 are planned again once the dust has settled?
No such plans exist. Your desire for a network-free install needs to be backed up by some work, as none of the core developers have that goal.
and second, does documentation exist which explains how to craft a monolithic tarball with zc.sourcerelease in order to build zope2.12 without network access? i still didn't get the picture regarding buildout, and thus don't understand zc.sourcerelease either :-/
A casual browse of the zc.sourcerelease page on PyPI yields: http://pypi.python.org/pypi/zc.sourcerelease#creating-source-releases-from-b... 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkwWQzsACgkQ+gerLs4ltQ5oTwCeOGZHOldy6fOZblczsbZ9rJtq iKIAn0lzIXtgFqb2jrPu1yo7RE4KqzN7 =Hsxl -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonas Meurer wrote:
thus i suggest to either provide monolithic tarballs which do contain the debendencies, or change release policy for the dependencies to not break backwards compability with every minor release.
I think this discussion pops up over and over again. I bring it back the point: the native distribution packages for Zope & friends are usually of interest for serious deployments. Our native deployment tool is 'buildout' as it is 'gem' for Ruby. Complete Python installations _by default_ are more in the interest of the end-user than having to deal with distribution specific problems that are not covered by the Zope & Python community. My 2 cents, Andreas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwVCJsACgkQCJIWIbr9KYyyRwCfXr8OdibDwNGcQ8NZpHqC/vso rigAnRN1qHfuYzL2X7AL0efyJLKBUOs1 =+Rqr -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonas Meurer wrote:
hey,
On 12/06/2010 Hanno Schlichting wrote:
What do we have in Zope 2.13:
[...]
Comments, suggestions, more work you'd like to get into 2.13?
another build system would be magnificent :-)
the new build system in zope2.12 makes it hard/impossible to distribute zope2 binaries within linux/*bsd/hurd/... distributions. so far no distribution i know contains zope2.12, and the most obvious reason is the new build system.
thus i suggest to either provide monolithic tarballs which do contain the debendencies, or change release policy for the dependencies to not break backwards compability with every minor release.
Maintaining the mechoanism to release that monolithic tarball is not on anybody's plate at the moment. At the point that somebody does the work to make it painlessly automated, then we can ask the release manager to include that task in the release process. Until somebody does that work, this item is effectively tabled. 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkwVGZ4ACgkQ+gerLs4ltQ5BKwCeIM41VBSJeGjEOe0J1EKKRYne 1yoAn1o6sUYJr9f5HJjlQjcCopEdzLWe =Ki1l -----END PGP SIGNATURE-----
Am 12.06.2010, 20:58 Uhr, schrieb Hanno Schlichting <hanno@hannosch.eu>:
Comments, suggestions, more work you'd like to get into 2.13?
Hi Hanno, thanks for the information. I'm a little confused by the narrative - is Plone 4.0 being held back by a Zope 2 release? As I don't use Plone I don't care about its release status and I don't think it should drive Zope's release status. Maybe that's what you were saying and I didn't understand it correctly. I'm also a little confused that your discussions have been with the "community" but not on this list. Not that this list should be the channel for all the discussions (it in its own way is as exclusive as many other channels). For the rest - deprecating zope.app on its own is probably a sufficiently large change to warrant a new point release which will hopefully tie into KGS. The same is true for five. Support for Python 2.7 would be great if doable (again not clear) and bumping the ZODB version. So the scope and schedule for the release is fine with me. We might want to add some of the issues to the weekly IRC meetings. 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
Hi Charlie, On Sun, Jun 13, 2010 at 2:06 PM, Charlie Clark <charlie.clark@clark-consulting.eu> wrote:
thanks for the information. I'm a little confused by the narrative - is Plone 4.0 being held back by a Zope 2 release?
No, Plone 4 is delayed for all the normal reasons of too many open bugs caused by the massive amount of changes it has seen. But Plone 4 being delayed also delays the next major Plone (5) release. Traditionally Plone has only upgraded to new major Zope versions in its own major versions.
As I don't use Plone I don't care about its release status and I don't think it should drive Zope's release status. Maybe that's what you were saying and I didn't understand it correctly.
The Zope 2 release schedule has for some time now effectively been synced to match the Plone release schedule. We have seen what happens with a Zope 2 release that isn't used in Plone with the Zope 2.11 release. It's not seen much of any maintenance and has only caused extra effort, as we were forced to maintain multiple branches for a longer time. As I said back in March, I want to avoid any Zope 2 release that isn't directly picked up by Plone. This is also the reason why I briefly discussed the roadmap with some people in the Plone community - to get buy-in on the idea and then made a proposal to this list. Hanno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Charlie Clark wrote:
thanks for the information. I'm a little confused by the narrative - is Plone 4.0 being held back by a Zope 2 release? As I don't use Plone I don't care about its release status and I don't think it should drive Zope's release status. Maybe that's what you were saying and I didn't understand it correctly.
Some clarifications: - - Plone doesn't "drive" the Zope2 release schedule, but we have often been willing (as with CMF) to push out releases because the Plone devs request them. - - Plone 4.0 is going to releaase with Zope 2.12.<latest> as its "supported" version of Zope2. - - The Plone framework team appears willing to be more aggressive (than the were for the 3.x line) about tracking newer Zope2 releases (i.e., Zope 2.13) in a 4.x release. - - Hanno has already done the work to ensure that CMF (latest and trunk) and Plone (4.0.x and 4.x) will work with a Zope 2.13. On the whole, I would actually favor getting a 2.13.0 out even sooner than Hanno suggests, to get it used (and therefore more polished) sooner. With the post-eggification reduction in Zope2's scope, I think a six month cycle for major releases would be a good target to aim at, rather than a year.
I'm also a little confused that your discussions have been with the "community" but not on this list. Not that this list should be the channel for all the discussions (it in its own way is as exclusive as many other channels).
Some of those discussions have been in IRC, or private e-mail, or on other lists (e.g., the plone-dev list).
For the rest - deprecating zope.app on its own is probably a sufficiently large change to warrant a new point release which will hopefully tie into KGS. The same is true for five. Support for Python 2.7 would be great if doable (again not clear) and bumping the ZODB version. So the scope and schedule for the release is fine with me. We might want to add some of the issues to the weekly IRC meetings.
I don't see much to discuss: landing all that stuff *is* going to trigger the new point release, and none of that is going to be backported to 2.12. 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkwU1AYACgkQ+gerLs4ltQ4KRACeNMGTqbyq2okUgQw9CWrmWT5X 3mkAoJl9NtSLB0uV+GKGWpf9dt90fFnY =T7Cm -----END PGP SIGNATURE-----
On Sun, Jun 13, 2010 at 2:50 PM, Tres Seaver <tseaver@palladion.com> wrote:
On the whole, I would actually favor getting a 2.13.0 out even sooner than Hanno suggests, to get it used (and therefore more polished) sooner. With the post-eggification reduction in Zope2's scope, I think a six month cycle for major releases would be a good target to aim at, rather than a year.
I agree that a shorter release cycle is going to be more suitable again. I'm a bit conservative for 2.13 to make sure we really have a ZTK release in place and Plone 4.1 is picking this up. If both of these turn out to be true, than I can see another ZTK release used in 2.14 and Plone 4.2 picking this up again. I expect those kind of releases to aim for six month and some of them languishing a bit to end up with more like nine month. Still a lot shorter than the effective one to two years we have now. Hanno
Hi there, thanks to all of you for the feedback. Given the general agreement to the plan, I'm going to release a first alpha on Friday June 25. More alpha releases will follow depending on the changes that go into the codebase. But I expect them on a roughly 3-4 weeks basis. If the code stays as stable as it is and no new major features come in, I expect to release a first beta in early September, in time for the German Zope User Group conference. The concrete plan up to the final will be decided once we get a beta out of the door. Thanks all, Hanno On Sat, Jun 12, 2010 at 8:58 PM, Hanno Schlichting <hanno@hannosch.eu> wrote:
Aim for having a Zope 2.13 release in time for Plone 4.1, get a first alpha release out by the end of the month or early July. We can have more alpha releases during the summer, a beta probably around the zope-dev summit / German Zope User Group conference in early September.
participants (5)
-
Andreas Jung -
Charlie Clark -
Hanno Schlichting -
Jonas Meurer -
Tres Seaver