I found a thread (from March 2006) discussing the future of zclasses, but i could not determine if a 'final' decision had been made. According to Changes.txt for Zope 2.10.0: "ZClasses are deprecated and should no longer be used. In addition any code related to the ZClasses (re)distribution mechanism is removed." Does this mean that any application which incorporates zclasses will break if upgraded to zope 2.10.x? The reason i ask is that i have a huge legacy system (zope 2.6) that is about to be upgraded to a more current version of zope, and i am wondering if this is the time to replace the zclass utilization (a seriously non-trivial task!). Thanks, Jonathan
--On 27. September 2006 12:42:23 -0400 Jonathan <dev101@magma.ca> wrote:
I found a thread (from March 2006) discussing the future of zclasses, but i could not determine if a 'final' decision had been made.
According to Changes.txt for Zope 2.10.0:
"ZClasses are deprecated and should no longer be used. In addition any code related to the ZClasses (re)distribution mechanism is removed."
Right. And nobody stepped in to work on an alternative solution. Another indication that the core developers don't care much about ZClasses.
Does this mean that any application which incorporates zclasses will break if upgraded to zope 2.10.x?
Likely.
The reason i ask is that i have a huge legacy system (zope 2.6) that is about to be upgraded to a more current version of zope, and i am wondering if this is the time to replace the zclass utilization (a seriously non-trivial task!).
It's definitely time to work on a replacement. -aj
----- Original Message ----- From: "Andreas Jung" <lists@zopyx.com> To: "Jonathan" <dev101@magma.ca>; <zope-dev@zope.org>
I found a thread (from March 2006) discussing the future of zclasses, but i could not determine if a 'final' decision had been made.
According to Changes.txt for Zope 2.10.0:
"ZClasses are deprecated and should no longer be used. In addition any code related to the ZClasses (re)distribution mechanism is removed."
Right. And nobody stepped in to work on an alternative solution. Another indication that the core developers don't care much about ZClasses.
Does this mean that any application which incorporates zclasses will break if upgraded to zope 2.10.x?
Likely.
Oh crap...
The reason i ask is that i have a huge legacy system (zope 2.6) that is about to be upgraded to a more current version of zope, and i am wondering if this is the time to replace the zclass utilization (a seriously non-trivial task!).
It's definitely time to work on a replacement.
Much louder 'oh crap...' Thanks for the insight, i now know what i am going to be doing for the foreseeable future ;-( ... i don't suppose anyone has an 'automagical' utility that instantly transforms zclasses to python classes, and then changes all dtml/external method usage do they? ...didn't think so ;-) Thanks again, Jonathan
--On 27. September 2006 13:47:26 -0400 Jonathan <dev101@magma.ca> wrote:
... i don't suppose anyone has an 'automagical' utility that instantly transforms zclasses to python classes, and then changes all dtml/external method usage do they? ...didn't think so ;-)
Also I don't think so. Just my personal opinion: ZClasses were the biggest mistake in the history of Zope :-) -aj -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
Andreas Jung skrev:
--On 27. September 2006 13:47:26 -0400 Jonathan <dev101@magma.ca> wrote:
... i don't suppose anyone has an 'automagical' utility that instantly transforms zclasses to python classes, and then changes all dtml/external method usage do they? ...didn't think so ;-)
Also I don't think so. Just my personal opinion: ZClasses were the biggest mistake in the history of Zope :-)
Only the implementation. The idea of interactively creating objects through the web is a brilliant idea.
Andreas Jung wrote:
--On 27. September 2006 13:47:26 -0400 Jonathan <dev101@magma.ca> wrote:
... i don't suppose anyone has an 'automagical' utility that instantly transforms zclasses to python classes, and then changes all dtml/external method usage do they? ...didn't think so ;-)
Also I don't think so. Just my personal opinion: ZClasses were the biggest mistake in the history of Zope :-)
ZClasses have been very good to us. It is a shame that I haven't had more time (and that no one else took an interest in) maintaining them. Jim
Jonathan wrote:
----- Original Message ----- From: "Andreas Jung" <lists@zopyx.com> To: "Jonathan" <dev101@magma.ca>; <zope-dev@zope.org>
I found a thread (from March 2006) discussing the future of zclasses, but i could not determine if a 'final' decision had been made.
According to Changes.txt for Zope 2.10.0:
"ZClasses are deprecated and should no longer be used. In addition any code related to the ZClasses (re)distribution mechanism is removed."
Right. And nobody stepped in to work on an alternative solution. Another indication that the core developers don't care much about ZClasses.
Does this mean that any application which incorporates zclasses will break if upgraded to zope 2.10.x?
Likely.
Oh crap...
Before you get to excited, you should probably try it. If it breaks, it is likely to break in small ways. I'm just guessing. ZClasses haven't been removed. It's just that I'm pretty much the only one who can fix them and I have lots of other priorities. :/ Jim
----- Original Message ----- From: "Jim Fulton" <jim@zope.com> To: "Jonathan" <dev101@magma.ca> Cc: "Andreas Jung" <lists@zopyx.com>; <zope-dev@zope.org> Sent: Wednesday, September 27, 2006 2:16 PM Subject: Re: [Zope-dev] Future of ZClasses
Jonathan wrote:
----- Original Message ----- From: "Andreas Jung" <lists@zopyx.com> To: "Jonathan" <dev101@magma.ca>; <zope-dev@zope.org>
I found a thread (from March 2006) discussing the future of zclasses, but i could not determine if a 'final' decision had been made.
According to Changes.txt for Zope 2.10.0:
"ZClasses are deprecated and should no longer be used. In addition any code related to the ZClasses (re)distribution mechanism is removed."
Right. And nobody stepped in to work on an alternative solution. Another indication that the core developers don't care much about ZClasses.
Does this mean that any application which incorporates zclasses will break if upgraded to zope 2.10.x?
Likely.
Oh crap...
Before you get to excited, you should probably try it. If it breaks, it is likely to break in small ways. I'm just guessing. ZClasses haven't been removed. It's just that I'm pretty much the only one who can fix them and I have lots of other priorities. :/
Jim
From a 'robustness' and 'sleep-better-at-nite' perspective I would rather spend the time making sure the application is rock-solid (by replacing the zclasses once and for all) and not have to worry about this issue everytime a new release of zope is installed.
I'm going to consider this a 'learning experience' ;-) BTW - nothing beats ZClasses and DTML for quick-and-dirty demos, one-time applications, and rapid-prototyping!
Jonathan wrote: ...
From a 'robustness' and 'sleep-better-at-nite' perspective I would rather spend the time making sure the application is rock-solid (by replacing the zclasses once and for all) and not have to worry about this issue everytime a new release of zope is installed.
Right. Applications that are gooing to be maintained over the long term should not use ZClasses, for a lot of reasons.
I'm going to consider this a 'learning experience' ;-)
BTW - nothing beats ZClasses and DTML for quick-and-dirty demos, one-time applications, and rapid-prototyping!
Exactly. Hopefully, your experience with your initial ZClass-based implementation can be applied to a more long-term solution. Jim
--On 27. September 2006 15:09:13 -0400 Jim Fulton <jim@zope.com> wrote:
Jonathan wrote: ...
From a 'robustness' and 'sleep-better-at-nite' perspective I would rather spend the time making sure the application is rock-solid (by replacing the zclasses once and for all) and not have to worry about this issue everytime a new release of zope is installed.
Right. Applications that are gooing to be maintained over the long term should not use ZClasses, for a lot of reasons.
That is exactly the case and because of this we must tell the people: ZClasses are a one-way road - no way out. Andreas
--On 28. September 2006 06:32:32 +0200 Andreas Jung <lists@zopyx.com> wrote:
--On 27. September 2006 15:09:13 -0400 Jim Fulton <jim@zope.com> wrote:
Jonathan wrote: ...
From a 'robustness' and 'sleep-better-at-nite' perspective I would rather spend the time making sure the application is rock-solid (by replacing the zclasses once and for all) and not have to worry about this issue everytime a new release of zope is installed.
Right. Applications that are gooing to be maintained over the long term should not use ZClasses, for a lot of reasons.
That is exactly the case and because of this we must tell the people: ZClasses are a one-way road - no way out.
But you might also go to Zope Corp. with a bag full of money and say: "Hey, ZClasses are important for me and my business. Could we make a project in order to get ZClasses in a better shape?"...depending on what's inside the bag, ZC might say yes or no :-) Andreas -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
Jonathan wrote:
BTW - nothing beats ZClasses and DTML for quick-and-dirty demos, one-time applications, and rapid-prototyping!
I prefer to use page templates, python scripts and PropertyManagers for this ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Jonathan wrote at 2006-9-27 12:42 -0400:
I found a thread (from March 2006) discussing the future of zclasses, but i could not determine if a 'final' decision had been made.
According to Changes.txt for Zope 2.10.0:
"ZClasses are deprecated and should no longer be used. In addition any code related to the ZClasses (re)distribution mechanism is removed."
Does this mean that any application which incorporates zclasses will break if upgraded to zope 2.10.x?
I do not think so. Jim invested considerable time to make ZClasses working for Zope 2.8. Future modififications will probably not break ZClasses severely. Also the thread that ZClass (re)distribution code will be removed need not worry you too much. Fortunately, Zope is open source and you can simply combine the new release with pieces of an older release to retain features essential to you. This way, the power of overly eager release managers (and other removal friendly Zope developers) is limited :-) We have a large ZClass based application. And I will keep it working. However, our current strategy is to skip more and more Zope releases (we are still at Zope 2.8.1) because the features newly introduced in the newer Zope releases are not worth the upgrade efforts. Currently, we plan our next upgrade to Zope 2.11 (to make use of "eggification"). Therefore, I cannot promiss to fix potential ZClass problems in Zope 2.10 in a timely manner. If eggification comes with Zope 2.11 (otherwise, we may delay our upgrade until Zope 2.12), then ZClasses will work again for this release. -- Dieter
----- Original Message ----- From: "Dieter Maurer" <dieter@handshake.de> To: "Jonathan" <dev101@magma.ca> Cc: <zope-dev@zope.org> Sent: Thursday, September 28, 2006 2:49 PM Subject: Re: [Zope-dev] Future of ZClasses
Jonathan wrote at 2006-9-27 12:42 -0400:
I found a thread (from March 2006) discussing the future of zclasses, but i could not determine if a 'final' decision had been made.
According to Changes.txt for Zope 2.10.0:
"ZClasses are deprecated and should no longer be used. In addition any code related to the ZClasses (re)distribution mechanism is removed."
Does this mean that any application which incorporates zclasses will break if upgraded to zope 2.10.x?
I do not think so.
Jim invested considerable time to make ZClasses working for Zope 2.8.
Future modififications will probably not break ZClasses severely.
Also the thread that ZClass (re)distribution code will be removed need not worry you too much. Fortunately, Zope is open source and you can simply combine the new release with pieces of an older release to retain features essential to you.
This way, the power of overly eager release managers (and other removal friendly Zope developers) is limited :-)
We have a large ZClass based application. And I will keep it working.
However, our current strategy is to skip more and more Zope releases (we are still at Zope 2.8.1) because the features newly introduced in the newer Zope releases are not worth the upgrade efforts. Currently, we plan our next upgrade to Zope 2.11 (to make use of "eggification"). Therefore, I cannot promiss to fix potential ZClass problems in Zope 2.10 in a timely manner.
If eggification comes with Zope 2.11 (otherwise, we may delay our upgrade until Zope 2.12), then ZClasses will work again for this release.
For internal applications I would rather leave the ZClasses in place and try to fix whatever breaks when zope is upgraded, however the application that caused my initial question is for an external client (with no in-house zope expertise of their own) and they are not at all pleased with the idea of having to 'fix things' everytime they update their zope version. In this particular instance, I am going to have to 'bite-the-bullet' and remove all traces of ZClasses, so that they can upgrade to future versions of zope without fear. On the plus side, they will end up with a more stable/robust application which, hopefully, will last for years to come! Jonathan
Jonathan wrote at 2006-9-28 15:11 -0400:
... For internal applications I would rather leave the ZClasses in place and try to fix whatever breaks when zope is upgraded, however the application that caused my initial question is for an external client (with no in-house zope expertise of their own) and they are not at all pleased with the idea of having to 'fix things' everytime they update their zope version.
Who speaks about every time (of an upgrade). I remember 2 (small) ZClass related problems after Zope upgrades and 1 time (for Zope 2.8) where ZClasses were not ready for the Zope beta version. The Zope 2.8 port of ZClasses was probably a significant effort (Thank's Jim). It is not unlikely that they will die should another such effort be necessary. However, for the next releases, no such effort is on the horizon. We might see small (unanticipated) problems like the 2 mentioned above.
In this particular instance, I am going to have to 'bite-the-bullet' and remove all traces of ZClasses, so that they can upgrade to future versions of zope without fear.
It is your choice. I will not argue against it.... -- Dieter
----- Original Message ----- From: "Dieter Maurer" <dieter@handshake.de> To: "Jonathan" <dev101@magma.ca> Cc: <zope-dev@zope.org> Sent: Thursday, September 28, 2006 4:21 PM Subject: Re: [Zope-dev] Future of ZClasses
Jonathan wrote at 2006-9-28 15:11 -0400:
... For internal applications I would rather leave the ZClasses in place and try to fix whatever breaks when zope is upgraded, however the application that caused my initial question is for an external client (with no in-house zope expertise of their own) and they are not at all pleased with the idea of having to 'fix things' everytime they update their zope version.
Who speaks about every time (of an upgrade).
I remember 2 (small) ZClass related problems after Zope upgrades and 1 time (for Zope 2.8) where ZClasses were not ready for the Zope beta version.
The Zope 2.8 port of ZClasses was probably a significant effort (Thank's Jim). It is not unlikely that they will die should another such effort be necessary.
However, for the next releases, no such effort is on the horizon.
We might see small (unanticipated) problems like the 2 mentioned above.
In this particular instance, I am going to have to 'bite-the-bullet' and remove all traces of ZClasses, so that they can upgrade to future versions of zope without fear.
It is your choice. I will not argue against it....
In this particular instance the client is a government department. They do not want to have an application that requires a specific skill set (ie. mine) in order to do an upgrade (they have an internal policy about keeping all o/s and application platforms current - which they do themselves). As much as I would like it, they do not want to hire me everytime they do an upgrade (could be a good business concept though!) Jonathan
Dieter Maurer wrote:
Also the thread that ZClass (re)distribution code will be removed need not worry you too much. Fortunately, Zope is open source and you can simply combine the new release with pieces of an older release to retain features essential to you.
I see no problem in making the "ZClasses" a separate svn.zope.org project, for example. That way they're not hindering Zope 2 core releases but could still be maintained (e.g. by volunteers like apparently yourself, Dieter :)) and shipped as an optional egg, for example. I don't see ZClasses as anything particular evil or good, just having them languish in the Zope 2 core puts a burden on all those who don't understand them and don't have the bandwidth to support them. So it's not about being "overly eager" regarding removal, it's about risk management for future releases. Moving ZClasses to a separate project reduces the risk of the Zope 2 core. Like you said, even you can't promise to keep ZClasses working for every Zope release...
We have a large ZClass based application. And I will keep it working.
Great!
--On 29. September 2006 02:23:13 +0200 Philipp von Weitershausen <philipp@weitershausen.de> wrote:
Dieter Maurer wrote:
Also the thread that ZClass (re)distribution code will be removed need not worry you too much. Fortunately, Zope is open source and you can simply combine the new release with pieces of an older release to retain features essential to you.
I see no problem in making the "ZClasses" a separate svn.zope.org project, for example. That way they're not hindering Zope 2 core releases but could still be maintained (e.g. by volunteers like apparently yourself, Dieter :)) and shipped as an optional egg, for example.
I think we should really make ZClasses available as separate package in Zope 2.11 since the current code seems to be borked for some ppl and because we dropped already some code (ZClasses distribution related staff). So moving ZClasses out of the Zope core is clear sign for any user: don't use ZClasses. Objections? Andreas
Andreas Jung wrote:
--On 29. September 2006 02:23:13 +0200 Philipp von Weitershausen <philipp@weitershausen.de> wrote:
Dieter Maurer wrote:
Also the thread that ZClass (re)distribution code will be removed need not worry you too much. Fortunately, Zope is open source and you can simply combine the new release with pieces of an older release to retain features essential to you.
I see no problem in making the "ZClasses" a separate svn.zope.org project, for example. That way they're not hindering Zope 2 core releases but could still be maintained (e.g. by volunteers like apparently yourself, Dieter :)) and shipped as an optional egg, for example.
I think we should really make ZClasses available as separate package in Zope 2.11 since the current code seems to be borked for some ppl and because we dropped already some code (ZClasses distribution related staff). So moving ZClasses out of the Zope core is clear sign for any user: don't use ZClasses.
Objections?
None from me. We just need to be careful about the rest of Zope. It may depend on ZClasses (e.g. notifying them when new disk products are there, etc.). That needs to be decoupled (perhaps using events?) Philipp
From: "Philipp von Weitershausen" <philipp@weitershausen.de> Sent: Saturday, 30 de September de 2006 18:56 Hello.
Also the thread that ZClass (re)distribution code will be removed need not worry you too much. Fortunately, Zope is open source and you can simply combine the new release with pieces of an older release to retain features essential to you.
I see no problem in making the "ZClasses" a separate svn.zope.org project, for example. That way they're not hindering Zope 2 core releases but could still be maintained (e.g. by volunteers like apparently yourself, Dieter :)) and shipped as an optional egg, for example.
+1
I think we should really make ZClasses available as separate package in Zope 2.11 since the current code seems to be borked for some ppl and because we dropped already some code (ZClasses distribution related staff). So moving ZClasses out of the Zope core is clear sign for any user: don't use ZClasses.
Objections?
Just a quick side note. Many "deprecation sign for any user" are clearly signs that Zope developers are unable to maintain certain Zope features. This is bad, specially for guys that have to manage large, complex and long time running zope installations ( think years ). And a "no sir, next app!" for guys like us who have to choose opensource development platforms for the long run ( again: think years ). BTW, ZClasses don't work as expected on 2.9.x. http://www.zope.org/Collectors/Zope/2005 "I'm punting to Jim, as he had better knowledge of how the persistent interfaces / specifications were supposed to work." :-) Best regards, @239, Nbk P.s. - Let's get back to zclasses -> python classes code week. %-)
On 10/2/06, Olavo Santos <lists@varkala.net> wrote:
Many "deprecation sign for any user" are clearly signs that Zope developers are unable to maintain certain Zope features.
No they are not. AFAIK there are only two features that have fallen out of maintainability, and that's ZClasses and the Zope support for ZODB version (which is more or less useless anyway). None of these got deprecated, they just broke. Deprecation is a sign that "this feature no longer lives here, but over here instead". -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Lennart Regebro said the following on 10/02/2006 11:16 AM:
On 10/2/06, Olavo Santos <lists@varkala.net> wrote:
Many "deprecation sign for any user" are clearly signs that Zope developers are unable to maintain certain Zope features.
No they are not.
Technically that is correct. Socially, as in "how others, eg,. mere users an developers of zope-based applications" *perceive* things, then it may very well be as Olavo S puts it. Especially when it comes to strategic decisions, eg. choosing development platform. I have no solution on how to solve this "problem", though, but I think we should be aware of it. /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. Lyrics applied to programming & application design: "emancipate yourself from mental slavery" - redemption song, b. marley
On 10/3/06, Dario Lopez-Kästen <dario@ita.chalmers.se> wrote:
Lennart Regebro said the following on 10/02/2006 11:16 AM:
On 10/2/06, Olavo Santos <lists@varkala.net> wrote:
Many "deprecation sign for any user" are clearly signs that Zope developers are unable to maintain certain Zope features.
No they are not.
Technically that is correct.
Socially, as in "how others, eg,. mere users an developers of zope-based applications" *perceive* things, then it may very well be as Olavo S puts it.
Especially when it comes to strategic decisions, eg. choosing development platform.
I have no solution on how to solve this "problem", though, but I think we should be aware of it.
The deprecations are indeed a sign that things are changing. This does in some way, indeed mean that the platform is unstable. Not as in "buggy", but as "rapidaly changing". Zope3 is therefore rapidly changing, and maybe even more so if you use it through Zope2 (ie Five). However, Zope2 in itself is NOT having very many deprecations, and is therefore NOT an unstable platform from this point of view. They only ones I can think of is the introduction of events instead of manage_afterAdd and such, and that is a VAST improvement over the previous situation, and backwards compatibility exist, and the much debated deprecation of zLOG. Neitehr of these were in any way a sign that anybody was unable to maintain features, and can simply not be reasonably (mis)interpreted as such. There HAVE been two signs of features not being able to be maintained, and those signs were both breakage. Breakage of ZODB version support, and breakage of ZClasses. Don't mix up deprecations with that. Deprecation are signs that things are moving fast, and is not a sign of lack of maintainance. Think of deprecations as a rerouting to another newly built road, while the lack of maintenance means that the road have holes in it. :) Too many newly build roads means drivers may get lost, and I think we ended up there in Zope3/Five, changes were too fast and too big, but done out of necessity. Zope2 has NOT experienced that. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On 10/2/06, Olavo Santos <lists@varkala.net> wrote:
Just a quick side note.
Many "deprecation sign for any user" are clearly signs that Zope developers are unable to maintain certain Zope features. This is bad, specially for guys that have to manage large, complex and long time running zope installations ( think years ). And a "no sir, next app!" for guys like us who have to choose opensource development platforms for the long run ( again: think years ).
Well, though nothing is perfect in Zope world, I think we are quite good in having a policy about deprecation which already gives a guaranteed timelime for deprecation. I wanted to find a deprecation policy for eclipse and JBoss to compare. For JBoss i did not find such a thing, for eclipse I did not find a eclipse framework one, but one for some sub projects: http://www.eclipse.org/webtools/adopters/#non-api-code-deprecation-policy and somehow this popped up in the eclipse search result: http://maven.apache.org/development/deprecation.html Notice especially how they mention that a deprecation phase can be days. So for me it looks we are actually a bit ahead of the competition, but maybe somebody can correct me. Accidently I lately tripped over an article from Martin Fowler about this topic: http://www.martinfowler.com/ieeeSoftware/published.pdf I think we use Interfaces in Z3 to "publish" Methods. So "maybe" it makes sense to have a smaller core API with longer deprecation periods, so that standard projects can try to rely on core API with long deprecation phase and extender would use the one year deprecation phase. But as I said earlier, I think we are quite ahead already. I guess the motivation of this API stability discussion is also motivated by JMOs comment about how much more stable is the Java API, in Point 2 and 3 of this entry: http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2006_09_23_times-the... But it is not fair to compare the stability of a programming language standard modules API with a application framework api. But maybe I am not good in searching and somebody points me to the well thought out JBoss or Websphere deprecation policy best regards, Patrick
On Wed, 2006-04-10 at 10:26 +0200, Patrick Gerken wrote:
Notice especially how they mention that a deprecation phase can be days. So for me it looks we are actually a bit ahead of the competition, but maybe somebody can correct me.
[snip...]
I think we use Interfaces in Z3 to "publish" Methods. So "maybe" it makes sense to have a smaller core API with longer deprecation periods, so that standard projects can try to rely on core API with long deprecation phase and extender would use the one year deprecation phase. But as I said earlier, I think we are quite ahead already.
[snip...]
But it is not fair to compare the stability of a programming language standard modules API with a application framework api. But maybe I am not good in searching and somebody points me to the well thought out JBoss or Websphere deprecation policy
Thanks for this insight. As a proponent of sensible deprecation it's nice to have some evidence rather than simply sputtering, "but but... we gotta be able to change stuff!" :) - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net
Patrick Gerken wrote:
On 10/2/06, Olavo Santos <lists@varkala.net> wrote:
Just a quick side note.
Many "deprecation sign for any user" are clearly signs that Zope developers are unable to maintain certain Zope features. This is bad, specially for guys that have to manage large, complex and long time running zope installations ( think years ). And a "no sir, next app!" for guys like us who have to choose opensource development platforms for the long run ( again: think years ).
Well, though nothing is perfect in Zope world, I think we are quite good in having a policy about deprecation which already gives a guaranteed timelime for deprecation. I wanted to find a deprecation policy for eclipse and JBoss to compare. For JBoss i did not find such a thing, for eclipse I did not find a eclipse framework one, but one for some sub projects: http://www.eclipse.org/webtools/adopters/#non-api-code-deprecation-policy
and somehow this popped up in the eclipse search result: http://maven.apache.org/development/deprecation.html
Notice especially how they mention that a deprecation phase can be days. So for me it looks we are actually a bit ahead of the competition, but maybe somebody can correct me.
Accidently I lately tripped over an article from Martin Fowler about this topic: http://www.martinfowler.com/ieeeSoftware/published.pdf
I think we use Interfaces in Z3 to "publish" Methods. So "maybe" it makes sense to have a smaller core API with longer deprecation periods, so that standard projects can try to rely on core API with long deprecation phase and extender would use the one year deprecation phase. But as I said earlier, I think we are quite ahead already.
I guess the motivation of this API stability discussion is also motivated by JMOs comment about how much more stable is the Java API, in Point 2 and 3 of this entry: http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2006_09_23_times-the...
But it is not fair to compare the stability of a programming language standard modules API with a application framework api. But maybe I am not good in searching and somebody points me to the well thought out JBoss or Websphere deprecation policy
best regards,
Patrick
Everyone deprecates stuff, this is not the question. But what is marked as 'stable', 'official' or 'standard' may not be deprecated in the same way as something that is still under development or private. It is more a question of defining and maintaining a contract with API users than a question of technicalities (how often to deprecate, what version numbers to use, how to inform...) This is all about defining and maintaining a social contract with the user. No one prevents you from deprecating parts of an API that is marked as being "under development" or "private" -- as long as you say it from the start. Check out for instance: http://openide.netbeans.org/tutorial/api-design.html especially the chapter "Life-cycle of an API" What is unclear in zope is what is "official", what is "stable", what is still "under development", etc. It seems that all the different packages have the same status, or rather that they have no status. Apart from the packages that were added recently (zc. ...) there is no information in the repository about the quality of the different APIs. There are no version numbers on the packages either so I don't know what is alpha, beta, or final. It gives the impression that the framework is stable, but not mature. I'd expect that the API defined in the 'interfaces.py' files for instance are 'official' in the sense that there is a commitment that the API is ready and that it won't change until the next major version, but I doubt that this is understood by everyone putting stuff into these files. in Java, you can mark a class as 'final', meaning that no one will be able to subclass it, or methods can be marked as 'private'. Abstract classes can specify the methods that must be implemented. Also if a class says that it implements an interface it has to implement it otherwise the code won't compile. Again this is all about defining contracts. Considering the standard JBoss modules, there is no way to compare with zope really since they strive to implement the specifications thoroughly (EJB3, JSR-168, ...) and the APIs are final already, so they don't change. For other modules (e.g. Seam) users are fully aware that parts of the specs may change. For more mature modules such as Hibernate, I am not aware that the API changes between minor versions. best regards /JM
Above all, I should mention that I believe this discussion is largely about Z3, and I do not live in Z3 world yet. Actually I am developing more in 2.7 currently. But the policy I state below is valid for 2.x also, afaik. On 10/4/06, Jean-Marc Orliaguet <jmo@ita.chalmers.se> wrote:
Patrick Gerken wrote:
I think we use Interfaces in Z3 to "publish" Methods. So "maybe" it makes sense to have a smaller core API with longer deprecation periods, so that standard projects can try to rely on core API with long deprecation phase and extender would use the one year deprecation phase. But as I said earlier, I think we are quite ahead already.
I guess the motivation of this API stability discussion is also motivated by JMOs comment about how much more stable is the Java API, in Point 2 and 3 of this entry:
Everyone deprecates stuff, this is not the question. But what is marked as 'stable', 'official' or 'standard' may not be deprecated in the same way as something that is still under development or private. It is more a question of defining and maintaining a contract with API users than a question of technicalities (how often to deprecate, what version numbers to use, how to inform...)
This is all about defining and maintaining a social contract with the user. No one prevents you from deprecating parts of an API that is marked as being "under development" or "private" -- as long as you say it from the start.
Check out for instance: http://openide.netbeans.org/tutorial/api-design.html especially the chapter "Life-cycle of an API"
I can see no guarantee for a time line
What is unclear in zope is what is "official", what is "stable", what is still "under development", etc. It seems that all the different packages have the same status, or rather that they have no status. Apart from the packages that were added recently (zc. ...) there is no information in the repository about the quality of the different APIs. There are no version numbers on the packages either so I don't know what is alpha, beta, or final. It gives the impression that the framework is stable, but not mature.
I'd expect that the API defined in the 'interfaces.py' files for instance are 'official' in the sense that there is a commitment that the API is ready and that it won't change until the next major version, but I doubt that this is understood by everyone putting stuff into these files.
Deprecation can happen at any time. Anything deprecated in one release will create deprecation warnings when used for two major releases. After that the code is removed. That is the official policy. Though I believe this was never mentioned explicitly, this policy relates to the releases packaged by Andreas and Philip. So for any code released in these packages this policy is used. I BELIEVE, this is also true for all other packages on svn.zope.org Through it is unclear, which of these have stable releases. I would say that everything just in svn is unstable, and stable is, what is in the zope core packages or on cheeseshop.
in Java, you can mark a class as 'final', meaning that no one will be able to subclass it, or methods can be marked as 'private'. Abstract classes can specify the methods that must be implemented. Also if a class says that it implements an interface it has to implement it otherwise the code won't compile.
So here I must admit that I am from Zope2 world mostly, but some smaller Z3 code I checked actually hat assertions in their code (not in the tests directory), that checks whether its own objects really obey the interface. This is worse than in Java but shows that at least these developers were aware of these things. Sadly, except for using Meta classes I see no way to make these checks implicit like they are in Java. This is a language problem.
Again this is all about defining contracts.
Considering the standard JBoss modules, there is no way to compare with zope really since they strive to implement the specifications thoroughly (EJB3, JSR-168, ...) and the APIs are final already, so they don't change.
Well, I can only answer with accusations like they influence the standards so much that you could already say they define the standard, and about the API I could ask how the react to changing environments, but that would not be fair, since I did not research the accusations nor how stable the API really is and what the API defines. Maybe somebody with better background can put these accusations on solid ground until then I have to believe Jean-Marc here. Anyway I appreciate your critics Jean-Marc. best regards, Patrick
participants (13)
-
Andreas Jung -
Chris Withers -
Dario Lopez-Kästen -
Dieter Maurer -
Jean-Marc Orliaguet -
Jim Fulton -
Jonathan -
Lennart Regebro -
Max M -
Olavo Santos -
Patrick Gerken -
Philipp von Weitershausen -
Rocky Burt