Proposal: Backporting some Python 2.5/2.6 fixes
Hi all, I would like to propose backporting some of the fixes needed for Python 2.5 and 2.6 all the way down to Zope 2.10. The fixes that would be backported would only be those that deal with syntax changes (eg: 'with' and 'as' keyword being used as variables, relative imports) and some C-level changes, to Acquisition and zope.app.container if I recall. I would *not* backport changes to RestrictedPython because those are actually features (support for newer versions of Python) as opposed to the other changes, which are just 'bugfixes' IMHO. Would anyone be against this? -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 Skype zopedc
On 27.10.2008 18:36 Uhr, Sidnei da Silva wrote:
Hi all,
I would like to propose backporting some of the fixes needed for Python 2.5 and 2.6 all the way down to Zope 2.10. The fixes that would be backported would only be those that deal with syntax changes (eg: 'with' and 'as' keyword being used as variables, relative imports) and some C-level changes, to Acquisition and zope.app.container if I recall. I would *not* backport changes to RestrictedPython because those are actually features (support for newer versions of Python) as opposed to the other changes, which are just 'bugfixes' IMHO.
Why do we need these backports on the current maintenance branches? Andreas
On Mon, Oct 27, 2008 at 3:42 PM, Andreas Jung <lists@zopyx.com> wrote:
Why do we need these backports on the current maintenance branches?
They are small cleanups that could potentially allow someone to run Python 2.5 or 2.6 if they really really really wanted to, but note should be made that it would be completely and utterly unsupported. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 Skype zopedc
On 27.10.2008 18:55 Uhr, Sidnei da Silva wrote:
On Mon, Oct 27, 2008 at 3:42 PM, Andreas Jung<lists@zopyx.com> wrote:
Why do we need these backports on the current maintenance branches?
They are small cleanups that could potentially allow someone to run Python 2.5 or 2.6 if they really really really wanted to, but note should be made that it would be completely and utterly unsupported.
Please create branches first and then lets review the changes. What is the state of the compatability of Z3 modules with Python 2.5/2.6 as used in Zope 2.10/2.11? Andreas
On Mon, Oct 27, 2008 at 4:06 PM, Andreas Jung <lists@zopyx.com> wrote:
Please create branches first and then lets review the changes.
Great.
What is the state of the compatability of Z3 modules with Python 2.5/2.6 as used in Zope 2.10/2.11?
Hard to tell at this point. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 Skype zopedc
Andreas Jung wrote:
On 27.10.2008 18:55 Uhr, Sidnei da Silva wrote:
On Mon, Oct 27, 2008 at 3:42 PM, Andreas Jung<lists@zopyx.com> wrote:
Why do we need these backports on the current maintenance branches?
They are small cleanups that could potentially allow someone to run Python 2.5 or 2.6 if they really really really wanted to, but note should be made that it would be completely and utterly unsupported.
Please create branches first and then lets review the changes. What is the state of the compatability of Z3 modules with Python 2.5/2.6 as used in Zope 2.10/2.11?
Zope 2.10 contains Zope 3.3 which most likely doesn't work on Python 2.5. Nobody has bothered to take a look, really, since it's ages old. Zope 2.11 contains the Zope 3.4 KGS, as far as I'm aware. If the 3.4 KGS refers to the latest bugfix releases of all packages, then it works on Python 2.5. Superficially, many Zope 3 packages also work on Python 2.6 (e.g. Grok runs), but a closer look reveals various test failures. IMHO we shouldn't worry about 2.10 and 2.11 and just care about 2.12 at this point. By now it should work with Python 2.5, right? Let's release it soonish. Not only will it bring Python 2.5 compatibility but it also gets rid of Acquisition-wrapped views and introduces (optional) __parent__ pointers. Three years after having started the implementation, I think it's time to get it out there :)
Philipp von Weitershausen wrote:
IMHO we shouldn't worry about 2.10 and 2.11 and just care about 2.12 at this point. By now it should work with Python 2.5, right? Let's release it soonish. Not only will it bring Python 2.5 compatibility but it also gets rid of Acquisition-wrapped views and introduces (optional) __parent__ pointers. Three years after having started the implementation, I think it's time to get it out there :)
When it comes to finding a good roadmap for a Zope 2.12 release, let me state a couple of my ideas, which I'd like to see in that release. Some of them are done, some of them should be done fairly soon and some might not make it. Still I'd put my list out here. Maybe there are others who have been thinking into the same direction. Here's a list of things I'd like to see in a 2.12 release: - Official Python 2.5 and 2.6 support (almost done, requires a community decision on when we call RestricedPython supported and reviewed) - Drop Python 2.4 support (so we can start relying on for example context managers and better generator support amongst others) - Finish the Zope2 as an egg work (almost done, but needs some final polishing) - Reduce the Zope3 dependencies of Zope2 to the actual required set (I'll work on this in the next weeks, together with Zope2-eggification) - Acquisition is aware of __parent__ pointers (done) - Make it possible to use the Zope3 meta ZCML handlers instead of the ones in Five This one needs a bit of explanation: It should be possible and supported to write a different site.zcml and load the Zope3 meta handlers. As these do have a different semantic in various places, there's no clear migration path from the Five meta.zcml handlers. But in order to get rid of the different base classes inserted by ZCML in the long term, we need to make it possible to use the Zope 3 versions at some point. This doesn't block a Zope 2.12 release, but would be a real good addition to the Acquistion versus __parent__ work and another step in the direction of getting rid of Five. - Let OFS.ObjectManager implement IContainer for real Since the inclusion of Five into Zope2 ObjectManager claims to implement the IContainer interface, but it actually doesn't. Since about Plone 2.1 Plone does monkey patch ObjectManager for that reason and adds the missing methods to it. I'd like to get rid of the monkey patch in Plone and let container.keys(), container.values(), ... become an official API in addition to container.objectIds() container.objectValues(), ... This is not trivial on the Zope level, we'd need to take care of items in all containers by the name of those new methods, but I believe a solution to that can be found. While this doesn't sound like a major problem, I think it does lower the learning curve. Telling people containers in Zope2 or essentially dictionaries is a lot easier then learning a complete new API. It should also make it easier to share code between implementations for Zope2 and Zope3. I know of code in Plone and add-ons that actually rely on these methods to be in place for many years now. - Reconsider getting rid of ZClasses I know this one is not popular, but from what I can see, the number of supporters of ZClasses are in a minority and the community at large has moved on into a different direction. Removed ZClasses would allow us to get rid of much weird code that is only written to support them, in both product initialization and things like the persistent product registry. Hanno
Previously Hanno Schlichting wrote:
Still I'd put my list out here. Maybe there are others who have been thinking into the same direction. Here's a list of things I'd like to see in a 2.12 release:
- Reconsider getting rid of ZClasses
I know this one is not popular, but from what I can see, the number of supporters of ZClasses are in a minority and the community at large has moved on into a different direction. Removed ZClasses would allow us to get rid of much weird code that is only written to support them, in both product initialization and things like the persistent product registry.
+1 In addition I would like to see some hooks to make plone.validatehook and plone.postpublicationhook obsolete. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Thu, Oct 30, 2008 at 15:03, Hanno Schlichting <hannosch@hannosch.eu> wrote:
- Reconsider getting rid of ZClasses
+1 I have some things I want to do when it coms to timezones, so I would like to mentally prepare me for about what release date we are talking about here, so I know when I have to do this. Could be a good xmas entertainment for example. :) -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64
On 30.10.2008 18:01 Uhr, Lennart Regebro wrote:
On Thu, Oct 30, 2008 at 15:03, Hanno Schlichting<hannosch@hannosch.eu> wrote:
- Reconsider getting rid of ZClasses
+1
I have some things I want to do when it coms to timezones, so I would like to mentally prepare me for about what release date we are talking about here, so I know when I have to do this. Could be a good xmas entertainment for example. :)
I think there is need for setting a release date right now - I know that this a total contradiction to our former approach with time-based releases. The current 2.11 codebase is pretty much in sync with the latest Zope web-components. Since the Zope 2 development is in parts driven by the Plone community and their needs, it does make sense keeping the development in some way in sync with the Plone 4 release. Not much to be added to the feature set as proposed by Hanno - except a dedicated +1 for getting rid of ZClasses. Andreas
Andreas Jung wrote:
I think there is need for setting a release date right now - I know that this a total contradiction to our former approach with time-based releases. The current 2.11 codebase is pretty much in sync with the latest Zope web-components. Since the Zope 2 development is in parts driven by the Plone community and their needs, it does make sense keeping the development in some way in sync with the Plone 4 release.
When it comes to a roadmap for Zope 2.12, I should probably comment on the Plone-side of this. I'm the current interim release manager for Plone 4.0 and there is a good chance I will end up being the final release manager for the Plone 4.x series. A final decision on this is pending due to our community processes. Plone 4.0 does not have a concrete roadmap yet. The general direction is in favor of making a true real step forward with Plone for the next major version. What that will mean in terms of features, depends on what is going to be written and contributed in the end. But we will allow major backwards incompatible changes in the release. We will not attempt a rewrite of Plone. Time-wise we are not very likely to see a Plone 4.0 final release anytime in the next 12 months. We will see development preview releases and these will most definitely all require Zope 2.12 and Python 2.6. So from a Plone perspective there is no demand for any soon feature freeze or release of Zope 2 itself. Alpha releases might come in handy during spring next year, but even beta versions are not going to be required or particular useful to us.
From what I know of other consumers of Zope 2, it seems Haufe doesn't have a need for any of the Zope 2.12 features at this point, but is using Zope 2.11 / Zope 3.4 as a development base.
I don't know the current status of Silva or if there are other major players left using Zope 2, which would benefit from a soon Zope 2.12 release. Please speak up, if you want to influence the roadmap for Zope 2 ;) Hanno
On 30.10.2008 19:38 Uhr, Hanno Schlichting wrote:
So from a Plone perspective there is no demand for any soon feature freeze or release of Zope 2 itself. Alpha releases might come in handy during spring next year, but even beta versions are not going to be required or particular useful to us.
The problem with the alpha and beta releases in the past were basically phases of long-term development. I know that the Zope 2 development is pretty unorganized (things happen when they happen). We should move your proposal somewhere to wiki.zope.org for having it as a reminder.
From what I know of other consumers of Zope 2, it seems Haufe doesn't have a need for any of the Zope 2.12 features at this point, but is using Zope 2.11 / Zope 3.4 as a development base.
There is no special need for a Zope 2.12 release from the Haufe side - we still have to catch up :-) Andreas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
Philipp von Weitershausen wrote:
IMHO we shouldn't worry about 2.10 and 2.11 and just care about 2.12 at this point. By now it should work with Python 2.5, right? Let's release it soonish. Not only will it bring Python 2.5 compatibility but it also gets rid of Acquisition-wrapped views and introduces (optional) __parent__ pointers. Three years after having started the implementation, I think it's time to get it out there :)
When it comes to finding a good roadmap for a Zope 2.12 release, let me state a couple of my ideas, which I'd like to see in that release. Some of them are done, some of them should be done fairly soon and some might not make it.
Still I'd put my list out here. Maybe there are others who have been thinking into the same direction. Here's a list of things I'd like to see in a 2.12 release:
- Official Python 2.5 and 2.6 support (almost done, requires a community decision on when we call RestricedPython supported and reviewed)
+1 for 2.5; I'm pretty sure 2.6 is not there yet, and may be too hard to aim for in one release.
- Drop Python 2.4 support (so we can start relying on for example context managers and better generator support amongst others)
- -1. Sugar is never sweet enough to give up the fallback to "known good." We should *not* be adding support for new Python versions and removing it for older ones in the same release.
- Finish the Zope2 as an egg work (almost done, but needs some final polishing)
+1.
- Reduce the Zope3 dependencies of Zope2 to the actual required set (I'll work on this in the next weeks, together with Zope2-eggification)
- Acquisition is aware of __parent__ pointers (done)
- Make it possible to use the Zope3 meta ZCML handlers instead of the ones in Five
This one needs a bit of explanation:
It should be possible and supported to write a different site.zcml and load the Zope3 meta handlers. As these do have a different semantic in various places, there's no clear migration path from the Five meta.zcml handlers. But in order to get rid of the different base classes inserted by ZCML in the long term, we need to make it possible to use the Zope 3 versions at some point. This doesn't block a Zope 2.12 release, but would be a real good addition to the Acquistion versus __parent__ work and another step in the direction of getting rid of Five.
- -0 for a 2.12 release. I don't see enough win to make it worth any delay.
- Let OFS.ObjectManager implement IContainer for real
Since the inclusion of Five into Zope2 ObjectManager claims to implement the IContainer interface, but it actually doesn't. Since about Plone 2.1 Plone does monkey patch ObjectManager for that reason and adds the missing methods to it.
I'd like to get rid of the monkey patch in Plone and let container.keys(), container.values(), ... become an official API in addition to container.objectIds() container.objectValues(), ...
This is not trivial on the Zope level, we'd need to take care of items in all containers by the name of those new methods, but I believe a solution to that can be found. While this doesn't sound like a major problem, I think it does lower the learning curve. Telling people containers in Zope2 or essentially dictionaries is a lot easier then learning a complete new API. It should also make it easier to share code between implementations for Zope2 and Zope3. I know of code in Plone and add-ons that actually rely on these methods to be in place for many years now.
+0.
- Reconsider getting rid of ZClasses
I know this one is not popular, but from what I can see, the number of supporters of ZClasses are in a minority and the community at large has moved on into a different direction. Removed ZClasses would allow us to get rid of much weird code that is only written to support them, in both product initialization and things like the persistent product registry.
There is already too much "superstition" around that code: there is no good reason for filesystem products to put anything in that registry at all, aside from nostalgia. OTOH, -1 to doing stuff just to appease the "Zope2-product-in-a-package-outside-the-Products-namespace" crowd: they didn't get the joke, there. Having stuff masquerading as "reusable Python" shich is still loaded up with Zope2 dependencies, including the expectation that it will have its 'initialize()' function called at startup, is silly. 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJCgfI+gerLs4ltQ4RAmgmAKDFO09wecuER19vYLHX3NF+9KYdXgCgidR9 37ulcN2TVF0Sl1aTRBLo3KM= =6jnQ -----END PGP SIGNATURE-----
- Official Python 2.5 and 2.6 support (almost done, requires a community decision on when we call RestricedPython supported and reviewed)
+1 for 2.5; I'm pretty sure 2.6 is not there yet, and may be too hard to aim for in one release.
What makes you think so? -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 Skype zopedc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sidnei da Silva wrote:
- Official Python 2.5 and 2.6 support (almost done, requires a community decision on when we call RestricedPython supported and reviewed) +1 for 2.5; I'm pretty sure 2.6 is not there yet, and may be too hard to aim for in one release.
What makes you think so?
A big pile of failing tests (not to mention DeprecationWarnings) when I build the trunk and run with Python 2.6:: $ cd projects/Zope-CVS/Zope-trunk $ svn up ... $ make clobber ... $ ../bin/python2.6 --version Python 2.6 $ ./configure --with-python="`cd .. && pwd`/bin/python2.6" \ && make inplace ... Zope binaries installed successfully ... $ ../bin/python/2.6 test.py --all ... Total: 6323 tests, 53 failures, 118 errors in 2 minutes 56.873 seconds. The corrsponding 2.4 and 2.5 builds have 3 test failures which you and I have been corrsponding about (the 'raise_standardErrorMessage' bit, plus the 'zope.testbrowser' failures -- see [1]); the 2.5 build also spews a non-trivial number of DeprecationWarnings. Those failures all seem to be incidental to landing the 2.5 - 2.6 compatibility changes from GSoC. [1] http://mail.zope.org/pipermail/zope-tests/2008-October/010393.html 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJCg/G+gerLs4ltQ4RAr8IAKC9sbn/oXI8AMgkh+OsqNL//3xzxACfVxCP uJbStS9X7u2VG51F+CKL9uk= =Bu1/ -----END PGP SIGNATURE-----
Tres Seaver wrote:
Hanno Schlichting wrote:
Here's a list of things I'd like to see in a 2.12 release:
- Official Python 2.5 and 2.6 support (almost done, requires a community decision on when we call RestricedPython supported and reviewed)
+1 for 2.5; I'm pretty sure 2.6 is not there yet, and may be too hard to aim for in one release.
Let me explain why I'd like to aim for Python 2.6 as a supported version from a Plone perspective. Plone's roadmap including true major versions looks like this: 1.0 - February 2003 2.1 - September 2005 3.0 - August 2007 4.0 - maybe late 2009 5.0 - not likely before 2011 My guesstimate says, we are going to release major new versions about every two years. This is a wild guesstimate but the best I have today. In addition I don't see us moving to new Python versions outside of those major version changes.
From my point of view it is desirable for us to be able to run Plone 4.0 based on Python 2.6 in about a year and use it as a stable version throughout 2010 and 2011.
By that time we will be three years after the release of Python 3. I'd like to be able to use those years to prepare our codebase for Python 3 and have a possibility to use it for Plone 5. Python 2.6 will give us the chance of preparing for that move. Maybe I'm going to be wrong and we will move to yearly major releases, maybe Plone dies, Python 3 is not adopted by anyone. All possible, but based on the knowledge I have today, not moving to Python 2.6 for the next major Plone version will leave us behind in a Python world, which has moved on.
From a Zope perspective 2.11 should have had Python 2.5 support, but nobody cared enough to make it happen. We can support Python 2.4 and 2.5 alone in Zope 2.12 and release it in the next months.
In that case Plone will neither use 2.11 nor 2.12 but go straight for a Zope 2.13 including Python 2.6. A major release every six month would be desirable for us in that case. Right now I don't see anyone, who would be using those releases. If those people exist, please speak up. Hanno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
Tres Seaver wrote:
Hanno Schlichting wrote:
Here's a list of things I'd like to see in a 2.12 release: - Official Python 2.5 and 2.6 support (almost done, requires a community decision on when we call RestricedPython supported and reviewed) +1 for 2.5; I'm pretty sure 2.6 is not there yet, and may be too hard to aim for in one release.
Let me explain why I'd like to aim for Python 2.6 as a supported version from a Plone perspective.
Plone's roadmap including true major versions looks like this:
1.0 - February 2003 2.1 - September 2005 3.0 - August 2007 4.0 - maybe late 2009 5.0 - not likely before 2011
My guesstimate says, we are going to release major new versions about every two years. This is a wild guesstimate but the best I have today. In addition I don't see us moving to new Python versions outside of those major version changes.
From my point of view it is desirable for us to be able to run Plone 4.0 based on Python 2.6 in about a year and use it as a stable version throughout 2010 and 2011.
By that time we will be three years after the release of Python 3. I'd like to be able to use those years to prepare our codebase for Python 3 and have a possibility to use it for Plone 5. Python 2.6 will give us the chance of preparing for that move.
Maybe I'm going to be wrong and we will move to yearly major releases, maybe Plone dies, Python 3 is not adopted by anyone. All possible, but based on the knowledge I have today, not moving to Python 2.6 for the next major Plone version will leave us behind in a Python world, which has moved on.
I'm fine with having Plone 4 able to run on a 2.6-compatible Zoep2. If we add Python 2.6 to the supported list for a no-later-than Q3 2009 Zope release, that should be sufficient, no?
From a Zope perspective 2.11 should have had Python 2.5 support, but nobody cared enough to make it happen. We can support Python 2.4 and 2.5 alone in Zope 2.12 and release it in the next months.
We should do a 2.12 very soon (before year end, likely), and it should retain 2.4 compatibility.
In that case Plone will neither use 2.11 nor 2.12 but go straight for a Zope 2.13 including Python 2.6. A major release every six month would be desirable for us in that case. Right now I don't see anyone, who would be using those releases. If those people exist, please speak up.
Plone isn't the only consumer of Zope2, although it is clearly the biggest one. Keeping an orderly succession of releases with good compatibility is important for the whole ecosystem (frankly, Plone should be willing to move to newer Zope versions even in a second dot release, but that is another debate). 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJChvx+gerLs4ltQ4RAm+nAJ9PwVjy4zOSXotiJafe/HYejjLH0wCcDFqC P8lcNefTAIZ1eVF6DHWx3Dc= =eFP2 -----END PGP SIGNATURE-----
Tres Seaver wrote:
Hanno Schlichting wrote: I'm fine with having Plone 4 able to run on a 2.6-compatible Zope2. If we add Python 2.6 to the supported list for a no-later-than Q3 2009 Zope release, that should be sufficient, no?
Sure!
From a Zope perspective 2.11 should have had Python 2.5 support, but nobody cared enough to make it happen. We can support Python 2.4 and 2.5 alone in Zope 2.12 and release it in the next months.
We should do a 2.12 very soon (before year end, likely), and it should retain 2.4 compatibility.
That is a perfectly fine and good plan.
In that case Plone will neither use 2.11 nor 2.12 but go straight for a Zope 2.13 including Python 2.6. A major release every six month would be desirable for us in that case. Right now I don't see anyone, who would be using those releases. If those people exist, please speak up.
Plone isn't the only consumer of Zope2, although it is clearly the biggest one. Keeping an orderly succession of releases with good compatibility is important for the whole ecosystem.
Please do not mistake this as a "this is how we should release Zope2 - Plone rulez" opinion. I'm trying to offer and communicate our roadmap, so it can be taken into account for the Zope2 roadmap. We are not the only consumer and Plone does have different priorities and practices than Zope. What is good and practical for Plone might still conflict with what is good and healthy for Zope. I'm very much interested in different opinions like yours, so we can get a good roadmap that fits all the different interest groups. Hanno
On 30.10.2008 21:41 Uhr, Tres Seaver wrote:
From a Zope perspective 2.11 should have had Python 2.5 support, but nobody cared enough to make it happen. We can support Python 2.4 and 2.5 alone in Zope 2.12 and release it in the next months.
We should do a 2.12 very soon (before year end, likely), and it should retain 2.4 compatibility.
What are our current needs for having a Python 2.5 compatible Zope 2 version (except it would be nice for having one). Being in sync with the latest Python 2.6 version is much more important than jumping on a half-dead horse like Python 2.5. Introducing another major Zope release with very little new exciting feature does not make sense to me at the time right now. It just adds another major release we have to support (we already support 2.9-2.11 and a bit 2.8) + the complexity for supporting two different Python versions for Zope 2.12. I am open to arguments but I really want to see why we need Zope 2.12 with Python 2.5 support this year (or at least very soon).
In that case Plone will neither use 2.11 nor 2.12 but go straight for a Zope 2.13 including Python 2.6. A major release every six month would be desirable for us in that case. Right now I don't see anyone, who would be using those releases. If those people exist, please speak up.
Plone isn't the only consumer of Zope2, although it is clearly the biggest one.
Tres, what are you current needs and requirements (properly based on your Repoze project)? I agree that Plone isn't the only consumer but I wonder if all other consumers really have the need jumping on every train passing the train station. We have the luxury with four supported Zope 2 major release. I don't want a fith right now unless we are having very good reasons.
Keeping an orderly succession of releases with good compatibility is important for the whole ecosystem (frankly, Plone should be willing to move to newer Zope versions even in a second dot release, but that is another debate).
This is already the case (more or less). In my experience strategic consumers are possibly more interested in slower release cycles instead of getting major releases very often. I doubt that much people care about using Python 2.4 or Python 2.5 (I personally don't care much about Python 2.5)..other feature likes e.g. a new ZODB version with some cool new feature is more important for justifying a new major release. If Sidnei should be successful with making Plone 2.11 compatible with Python 2.5 then we might add "inofficial" support for Python 2.5 to the current Zope 2.11 release...but as stated earlier I would like to see some arguments why Python 2.5 compatiblity is necessary now and why Python 2.6 support at some time next year would not be good enough. Andreas
On Fri, Oct 31, 2008 at 4:28 AM, Andreas Jung <lists@zopyx.com> wrote:
If Sidnei should be successful with making Plone 2.11 compatible with Python 2.5 then we might add "inofficial" support for Python 2.5 to the current Zope 2.11 release...but as stated earlier I would like to see some arguments why Python 2.5 compatiblity is necessary now and why Python 2.6 support at some time next year would not be good enough.
That's a great suggestion, and I believe we can achieve a middle ground solution here if there are more people interested in a short-term release that only adds Python 2.5 support. The idea there would be to branch a 2.12 off the 2.11 branch and only add Python 2.5 fixes on top of it, and maybe possibly a new ZODB. -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 Skype zopedc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote:
On 30.10.2008 21:41 Uhr, Tres Seaver wrote:
What are our current needs for having a Python 2.5 compatible Zope 2 version (except it would be nice for having one). Being in sync with the latest Python 2.6 version is much more important than jumping on a half-dead horse like Python 2.5. Introducing another major Zope release with very little new exciting feature does not make sense to me at the time right now. It just adds another major release we have to support (we already support 2.9-2.11 and a bit 2.8) + the complexity for supporting two different Python versions for Zope 2.12. I am open to arguments but I really want to see why we need Zope 2.12 with Python 2.5 support this year (or at least very soon).
In that case Plone will neither use 2.11 nor 2.12 but go straight for a Zope 2.13 including Python 2.6. A major release every six month would be desirable for us in that case. Right now I don't see anyone, who would be using those releases. If those people exist, please speak up. Plone isn't the only consumer of Zope2, although it is clearly the biggest one.
Tres, what are you current needs and requirements (properly based on your Repoze project)? I agree that Plone isn't the only consumer but I wonder if all other consumers really have the need jumping on every train passing the train station. We have the luxury with four supported Zope 2 major release. I don't want a fith right now unless we are having very good reasons.
I think we need to move toward 2.6 compatibility, but we need to give people a migration path, largely because 2.6 will break 3rd party apps in ways that 2.4 doesn't warn about. So, I would like to see a 2.12 which is explicity about bridging first to 2.5 support: that way, people get a chance to clean up the new deprecation warnings (e.g., for the 'with' keyword, etc.). If ZODB 3.9 lands in time, then a near-term release of Zope 2.12 could be this consolidation release (2.5 support, new ZODB, including maybe RelStorage, other work done to date). We could the focus trunk development on 2.6 compatibility, with the goal of releasing a 2.13 no later than Q3 next year. In the meantime, we can acknowledge that 2.8 and 2.9 are "retired" (no future work except maybe important security fixes), and announce that 2.10 will be retired after the 2.12 release: that may be incentive enough for Plone 3.3 to ship on 2.12, for instance. WRT repoze: except for the 'repoze.zope2' and 'repoze.plone' packages, we already have 2.5 / 2.6 support in hand, and in fact are deploying non-Zope2 customer applications using both versions.
Keeping an orderly succession of releases with good compatibility is important for the whole ecosystem (frankly, Plone should be willing to move to newer Zope versions even in a second dot release, but that is another debate).
This is already the case (more or less). In my experience strategic consumers are possibly more interested in slower release cycles instead of getting major releases very often. I doubt that much people care about using Python 2.4 or Python 2.5 (I personally don't care much about Python 2.5)..other feature likes e.g. a new ZODB version with some cool new feature is more important for justifying a new major release.
If Sidnei should be successful with making Plone 2.11 compatible with Python 2.5 then we might add "inofficial" support for Python 2.5 to the current Zope 2.11 release...but as stated earlier I would like to see some arguments why Python 2.5 compatiblity is necessary now and why Python 2.6 support at some time next year would not be good enough.
I don't see a win there, myself: I'd rather make an easier transition for 2.12 than spend resources on a potentially-destabilizing backport of 2.5 compatibility. 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJC0Ia+gerLs4ltQ4RAv8MAKDJAgpzus+Oh86aH0RgbGEXh26EDgCfQUL/ cnb/9SyKbWUg/JwqmC7tv5w= =qvj8 -----END PGP SIGNATURE-----
On 31.10.2008 18:36 Uhr, Tres Seaver wrote:
In that case Plone will neither use 2.11 nor 2.12 but go straight for a Zope 2.13 including Python 2.6. A major release every six month would be desirable for us in that case. Right now I don't see anyone, who would be using those releases. If those people exist, please speak up. Plone isn't the only consumer of Zope2, although it is clearly the biggest one. Tres, what are you current needs and requirements (properly based on your Repoze project)? I agree that Plone isn't the only consumer but I wonder if all other consumers really have the need jumping on every train passing the train station. We have the luxury with four supported Zope 2 major release. I don't want a fith right now unless we are having very good reasons.
I think we need to move toward 2.6 compatibility, but we need to give people a migration path, largely because 2.6 will break 3rd party apps in ways that 2.4 doesn't warn about. So, I would like to see a 2.12 which is explicity about bridging first to 2.5 support: that way, people get a chance to clean up the new deprecation warnings (e.g., for the 'with' keyword, etc.).
If ZODB 3.9 lands in time, then a near-term release of Zope 2.12 could be this consolidation release (2.5 support, new ZODB, including maybe RelStorage, other work done to date).
Good points - let's head for Python 2.5 support in Zope 2.12.
We could the focus trunk development on 2.6 compatibility, with the goal of releasing a 2.13 no later than Q3 next year.
ACK
In the meantime, we can acknowledge that 2.8 and 2.9 are "retired" (no future work except maybe important security fixes),
+1
and announce that 2.10 will be retired after the 2.12 release:
We have to care about 2.10 for a longer period because of the large amount of Plone 3.X installations.
I don't see a win there, myself: I'd rather make an easier transition for 2.12 than spend resources on a potentially-destabilizing backport of 2.5 compatibility.
ok - the goals for the 2.12 release should be documented somewhere (your ideas, see above + the Hanno's proposals). Andreas -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 4, 2008, at 09:10 , Andreas Jung wrote:
In the meantime, we can acknowledge that 2.8 and 2.9 are "retired" (no future work except maybe important security fixes),
+1
and announce that 2.10 will be retired after the 2.12 release:
We have to care about 2.10 for a longer period because of the large amount of Plone 3.X installations.
While there have been attempts to come up with an orderly release schedule I don't think anyone ever suggested some kind of deprecation scheme for Zope versions. It would be very helpful for everyone in the community to have a place to go where they can see which versions are in which "support state". So far Zope versions just slipped into unsupported state by some implied - but unstated - consensus. Clearly, it's impossible to support all these versions from 2.8 to 2.12, +1 from me for dropping 2.8 and 2.9. Just make sure this is mentioned somewhere obvious. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkQFvkACgkQRAx5nvEhZLIP5wCfUj+XMB8JZguAC8Gje9dcgYSD Fb0AnRjFPYihYKesoXZMxhhExfSYoJdO =DJ8R -----END PGP SIGNATURE-----
Jens Vagelpohl wrote:
On Nov 4, 2008, at 09:10 , Andreas Jung wrote:
In the meantime, we can acknowledge that 2.8 and 2.9 are "retired" (no future work except maybe important security fixes),
+1
and announce that 2.10 will be retired after the 2.12 release: We have to care about 2.10 for a longer period because of the large amount of Plone 3.X installations.
While there have been attempts to come up with an orderly release schedule I don't think anyone ever suggested some kind of deprecation scheme for Zope versions. It would be very helpful for everyone in the community to have a place to go where they can see which versions are in which "support state". So far Zope versions just slipped into unsupported state by some implied - but unstated - consensus.
Clearly, it's impossible to support all these versions from 2.8 to 2.12, +1 from me for dropping 2.8 and 2.9. Just make sure this is mentioned somewhere obvious.
From what I remember there have been discussions around this while attempting to get to a six-month time based release cycle at some point.
If I'm not mistaken there was something about every release being supported two years after its initial release in those discussions. But time went on, we haven't sticked to a time-based release schedule and those policies haven't been written down or been followed. So it's probably time to document and decide on them once again :) Hanno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Nov 4, 2008, at 13:59 , Hanno Schlichting wrote:
If I'm not mistaken there was something about every release being supported two years after its initial release in those discussions.
But time went on, we haven't sticked to a time-based release schedule and those policies haven't been written down or been followed.
2 years sounds fine to me. By that reasoning, we can stop supporting 2.8 (2.8.0 was released June 11, 2005) and 2.9 (2.9.0 was released January 9, 2006). However, if we were strict it would also mean EOL for 2.10 (2.10.0 was released October 4, 2006). But we can be lenient... jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkQhBUACgkQRAx5nvEhZLJULgCgqQiCKyA/PXgQPDastrc2dGgU ucAAn3qBkt52dJsbU/e1yOtYIsvmxAOw =88Sa -----END PGP SIGNATURE-----
Jens Vagelpohl wrote:
On Nov 4, 2008, at 13:59 , Hanno Schlichting wrote:
If I'm not mistaken there was something about every release being supported two years after its initial release in those discussions.
But time went on, we haven't sticked to a time-based release schedule and those policies haven't been written down or been followed.
2 years sounds fine to me.
By that reasoning, we can stop supporting 2.8 (2.8.0 was released June 11, 2005) and 2.9 (2.9.0 was released January 9, 2006). However, if we were strict it would also mean EOL for 2.10 (2.10.0 was released October 4, 2006). But we can be lenient...
+1 to retiring 2.8, 2.9. Of course, if people still want to maintain it, they should be welcome to. I just don't think we should have to merge bugfixes to those branches anymore. Maintaining 2.10, 2.11, trunk seems perfectly acceptable and it's plenty to deal with.
On 04.11.2008 18:19 Uhr, Jens Vagelpohl wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Nov 4, 2008, at 13:59 , Hanno Schlichting wrote:
If I'm not mistaken there was something about every release being supported two years after its initial release in those discussions.
But time went on, we haven't sticked to a time-based release schedule and those policies haven't been written down or been followed.
2 years sounds fine to me.
By that reasoning, we can stop supporting 2.8 (2.8.0 was released June 11, 2005) and 2.9 (2.9.0 was released January 9, 2006). However, if we were strict it would also mean EOL for 2.10 (2.10.0 was released October 4, 2006). But we can be lenient...
We must be careful with such time-based policies because of the installed (Plone) installations. Zope 2.8 and Zope 2.9 are definitely dead horses. We must support Zope 2.10 (which is a pretty good release) as long as Plone 3.X is supported. Let's say Plone 4 becomes mature in late 2009 and widely used by 2010...then we can talk about getting rid of 2.10 (except the Plone releases >= 3.2 would adopt Zope 2.11 or 2.12 at some point but I haven't heard that this is on the agenda for the next Plone 3.X releases). Andreas
Andreas Jung wrote:
On 04.11.2008 18:19 Uhr, Jens Vagelpohl wrote:
On Nov 4, 2008, at 13:59 , Hanno Schlichting wrote:
If I'm not mistaken there was something about every release being supported two years after its initial release in those discussions.
But time went on, we haven't sticked to a time-based release schedule and those policies haven't been written down or been followed.
2 years sounds fine to me.
We must be careful with such time-based policies because of the installed (Plone) installations. Zope 2.8 and Zope 2.9 are definitely dead horses. We must support Zope 2.10 (which is a pretty good release) as long as Plone 3.X is supported. Let's say Plone 4 becomes mature in late 2009 and widely used by 2010...then we can talk about getting rid of 2.10 (except the Plone releases >= 3.2 would adopt Zope 2.11 or 2.12 at some point but I haven't heard that this is on the agenda for the next Plone 3.X releases).
There are currently no plans to switch to a new Zope version for neither Plone 3.2 or 3.3. There are no plans or even a preliminary roadmap for a Plone 3.4 release yet. It would be something like a summer or autumn 2009 release. I think we will have some kind of feedback loop here, which makes it a good idea from a Plone perspective to upgrade to at least Zope 2.11 for Plone 3.4, as Zope 2.10 by whatever date that will be, is going to be an old an rather unmaintained release. So sticking to support 2.10, 2.11 and trunk right now and phasing out 2.10 sometime next year, sounds like a good roadmap to me. Hanno
On 04.11.2008 18:41 Uhr, Hanno Schlichting wrote:
Andreas Jung wrote:
On 04.11.2008 18:19 Uhr, Jens Vagelpohl wrote:
On Nov 4, 2008, at 13:59 , Hanno Schlichting wrote:
If I'm not mistaken there was something about every release being supported two years after its initial release in those discussions.
But time went on, we haven't sticked to a time-based release schedule and those policies haven't been written down or been followed. 2 years sounds fine to me. We must be careful with such time-based policies because of the installed (Plone) installations. Zope 2.8 and Zope 2.9 are definitely dead horses. We must support Zope 2.10 (which is a pretty good release) as long as Plone 3.X is supported. Let's say Plone 4 becomes mature in late 2009 and widely used by 2010...then we can talk about getting rid of 2.10 (except the Plone releases>= 3.2 would adopt Zope 2.11 or 2.12 at some point but I haven't heard that this is on the agenda for the next Plone 3.X releases).
There are currently no plans to switch to a new Zope version for neither Plone 3.2 or 3.3. There are no plans or even a preliminary roadmap for a Plone 3.4 release yet. It would be something like a summer or autumn 2009 release.
I think we will have some kind of feedback loop here, which makes it a good idea from a Plone perspective to upgrade to at least Zope 2.11 for Plone 3.4, as Zope 2.10 by whatever date that will be, is going to be an old an rather unmaintained release.
So sticking to support 2.10, 2.11 and trunk right now and phasing out 2.10 sometime next year, sounds like a good roadmap to me.
ok,ok - I'll stop caring to much about the Plone world :-) Andreas
Sidnei da Silva wrote:
I would like to propose backporting some of the fixes needed for Python 2.5 and 2.6 all the way down to Zope 2.10. The fixes that would be backported would only be those that deal with syntax changes (eg: 'with' and 'as' keyword being used as variables, relative imports) and some C-level changes, to Acquisition and zope.app.container if I recall. I would *not* backport changes to RestrictedPython because those are actually features (support for newer versions of Python) as opposed to the other changes, which are just 'bugfixes' IMHO.
Would anyone be against this?
I find this pretty disturbing as it implies you *would* be running Zope 2.10 on Python 2.5 or 2.6 without fixing RestrictedPython. Now, given that what you probably mean is that you want to run Plone on Python 2.6 and given Plone's *heavy* reliance of RestrictedPython, this seems like a bad idea all round. If you want to see Zope 2.10+ run on Python 2.5/2.6, then you'll need to do the job properly... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Sidnei da Silva wrote:
I would like to propose backporting some of the fixes needed for Python 2.5 and 2.6 all the way down to Zope 2.10.
I would *not* backport changes to RestrictedPython because those are actually features (support for newer versions of Python) as opposed to the other changes, which are just 'bugfixes' IMHO.
Would anyone be against this?
I find this pretty disturbing as it implies you *would* be running Zope 2.10 on Python 2.5 or 2.6 without fixing RestrictedPython.
RestrictedPython is its own package. If Zope 2.10 / 2.11 does not produce errors when being run under Python 2.5/2.6, you obviously need to run the latest RestrictedPython version with it to get a complete functioning system. Since RestrictedPython is its own package this is easy to do. As long as we don't advertise any kind of support for Zope 2.10 / 2.11 and Python 2.5 and 2.6 I don't see a problem with Sidnei's suggestion. Having a them available for review in a branch as Andreas requested is still a good idea. Hanno
Hanno Schlichting wrote:
Would anyone be against this? I find this pretty disturbing as it implies you *would* be running Zope 2.10 on Python 2.5 or 2.6 without fixing RestrictedPython.
RestrictedPython is its own package.
...which python scripts and page templates rely on heavilly.
If Zope 2.10 / 2.11 does not produce errors
It's not errors that I'm worried about, it's security holes.
to run the latest RestrictedPython version with it to get a complete functioning system.
You're missing the point.
Having a them available for review in a branch as Andreas requested is still a good idea.
Indeed. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (9)
-
Andreas Jung -
Chris Withers -
Hanno Schlichting -
Jens Vagelpohl -
Lennart Regebro -
Philipp von Weitershausen -
Sidnei da Silva -
Tres Seaver -
Wichert Akkerman