RE: [Zope] Does anyone care whether we deprecate ZClasses?
SOS This would mean a disaster for us. We've created a lot products using ZClasses in production environment (internet,intranet,eai and so on) since zope-2.1.4. In short our complete developement in Zope is heavily based on ZClasses. We plan to use ZClasses in the future, too. For us ZClasses are a essential part of zope and they works very well. It is quite impossible for us to migrate all our Products to python-products or somethong else and i guess that this is not wanted by you!? I think that going away from ZClasses will let many other people with legacy-software running in the same problems. regards ralph
Arenz, Ralph escribió:
SOS
This would mean a disaster for us. We've created a lot products using ZClasses in production environment (internet,intranet,eai and so on) since zope-2.1.4. In short our complete developement in Zope is heavily based on ZClasses.
We plan to use ZClasses in the future, too. For us ZClasses are a essential part of zope and they works very well. It is quite impossible for us to migrate all our Products to python-products or somethong else and i guess that this is not wanted by you!?
I think that going away from ZClasses will let many other people with legacy-software running in the same problems.
regards
ralph _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Hi Can you explain why you can't migrate from ZClasses to python-products? Perhaps the best solution will be create a machinery to migrate ZClasses Thanks!
On the Paris sprint, one thing that was noted was how ironic it was that the release of 2.8, which includes support for the new recommended development paradigm, was held up becuase we neeeded to support an old non-recommended one. :-) Anyway, my main question is: You who are using ZClasses, can't you just stay on Zope2.8 or 2.9, if Zope 2.10 would not contain ZClass support? The main features of 2.8 is support for the component architecture, and for zope 2.9 and 2.10 this will be even more true: there will most likely be very few new features besides this. With 2.9 or 2.10 the idea is that you can use both ZClasses, *and* write products that work under Zope3. I'm not even sure there will be a 2.10, and in any case you won't really have much need of it. I think it's a good idea to deprecate ZClasses if only to get people to start moving over to the Zope3 based development paradigm.
Lennart Regebro said:
Anyway, my main question is: You who are using ZClasses, can't you just stay on Zope2.8 or 2.9, if Zope 2.10 would not contain ZClass support?
That is possible, but it would be nice to be able to transition out of ZClasses through 2.8 -> 2.9 -> 2.10 as opposed to there being a drop off cliff. I think the idea of creating a ZCLass based pluging/product for 2.10 sounds like a good one. That was it can be rolled out of the ZOpe core and maintained by those of us who care. Jake -- http://www.ZopeZone.com
Lennart Regebro wrote at 2005-4-5 11:48 +0200:
On the Paris sprint, one thing that was noted was how ironic it was that the release of 2.8, which includes support for the new recommended development paradigm, was held up becuase we neeeded to support an old non-recommended one. :-)
"ZClasses" feature prominently in the Zope book. Seems they are more recommended than the new development paradigm (which does not yet feature at all in the Zope book). -- Dieter
And that is probably the best arguement for keeping them around longer. Until the documentation has caught up to the new features, it seems a bit ahead of schedule to start dropping support for them. Jake -- http://www.ZopeZone.com Dieter Maurer said:
Lennart Regebro wrote at 2005-4-5 11:48 +0200:
On the Paris sprint, one thing that was noted was how ironic it was that the release of 2.8, which includes support for the new recommended development paradigm, was held up becuase we neeeded to support an old non-recommended one. :-)
"ZClasses" feature prominently in the Zope book.
Seems they are more recommended than the new development paradigm (which does not yet feature at all in the Zope book).
-- Dieter _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
--On Dienstag, 5. April 2005 16:38 Uhr -0400 Jake <jake@zopezone.com> wrote:
And that is probably the best arguement for keeping them around longer.
We should get to the point: if some people depend on ZClasses then they should take over some responsibility in maintaining them in future releases. It can not be that a "feature" regarded as obsolete (from the majority) and almost unmaintained and untouched since ages holds up further releases. I agree with Jim that they should be officially deprecated - means they could be removed in Zope 2.10. We could leave them longer if they should work in further releases without further work. If there are serious problems in further releases with ZClasses holding up a new release we should kick them. So if you depend on ZClasses....learn how they are implemented and maintain them in the future. But from the prospective of limited resource it is not reasonable to spend much time on ZClasses in the future. -aj
On Apr 6, 2005, at 6:59, Andreas Jung wrote:
--On Dienstag, 5. April 2005 16:38 Uhr -0400 Jake <jake@zopezone.com> wrote:
And that is probably the best arguement for keeping them around longer.
We should get to the point: if some people depend on ZClasses then they should take over some responsibility in maintaining them in future releases. It can not be that a "feature" regarded as obsolete (from the majority) and almost unmaintained and untouched since ages holds up further releases.
Amen. Actually, instead of maintaining them in the core the current users should immediately look at breaking it out of the core into a separate product, as suggested earlier, and maintain that product. I believe that would make it simpler both from a Zope maintainer perspective as well as from the ZClass maintainers' perspective. jens
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jens Vagelpohl wrote:
On Apr 6, 2005, at 6:59, Andreas Jung wrote:
--On Dienstag, 5. April 2005 16:38 Uhr -0400 Jake <jake@zopezone.com> wrote:
And that is probably the best arguement for keeping them around longer.
We should get to the point: if some people depend on ZClasses then they should take over some responsibility in maintaining them in future releases. It can not be that a "feature" regarded as obsolete (from the majority) and almost unmaintained and untouched since ages holds up further releases.
Amen. Actually, instead of maintaining them in the core the current users should immediately look at breaking it out of the core into a separate product, as suggested earlier, and maintain that product. I believe that would make it simpler both from a Zope maintainer perspective as well as from the ZClass maintainers' perspective.
Perhaps once Jim's current work lands, that might be possible. As it is, most of the work to make ZClasses function in Zope 2.8 has been at the ZODB level (I think); I doubt that anyone (except Dieter!) plans to dive from the frying pan of ZClass implementation into the fire of ZODB code any time soon. Tres. - -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCU+hUGqWXf00rNCgRAup2AJ9myFbD3V2bjtrHRZPJMcwc9zN2cgCeMiet D/BUc+yQN82oY1MiaTBdr4U= =zSDn -----END PGP SIGNATURE-----
Tres Seaver wrote at 2005-4-6 09:47 -0400:
... Perhaps once Jim's current work lands, that might be possible. As it is, most of the work to make ZClasses function in Zope 2.8 has been at the ZODB level (I think); I doubt that anyone (except Dieter!) plans to dive from the frying pan of ZClass implementation into the fire of ZODB code any time soon.
And me, too, I am *VERY* happy that Jim proposed to make ZClasses work again with the new ExtensionClass'es (and does not abandon ZClasses right now). -- Dieter
Is this a kafkanian situation? Are really core developers asking the community to kick a used Zope's feature, saying it's because it's hard to maintain it, and simultaneously to say it's code 'unmaintained and untouched since ages'? Folks, you didn't need to ask for the aproval of people who didn't make it with that feature. You just do it. You're the ones that create the knots and know for sure where they are, and if you aren't in the mood anymore just give the thing over. :) As of your remarks, Andreas, I understand your point. People who care should take over. Sounds fair. Just please don't mean that we who say yes to a Jim's question are guilty of not letting Zope to move on, because Zope is moving to X3, not to 2.X+five, and definitely not to Archetypes, a CMF subject. As for ZC, IMHO the issue should be treated as a matter of understanding the market rather than achieving a milestone. You created stuff that works in some way or another that people embraced. You also changed your company name to the name of the product of yours that people embraced. And no matter how much hype there is on new trends, you should realize that a song is just a song until the market say it's a hit, and that X3 is that song. Shall you start to put Zope2 into pieces before getting to know you already have a hit? :) Ausum ----- Original Message ----- From: "Andreas Jung" <lists@andreas-jung.com> To: <jake@zopezone.com>; "Dieter Maurer" <dieter@handshake.de> Cc: <zope@zope.org> Sent: Tuesday, April 05, 2005 11:59 PM Subject: Re: [Zope] Does anyone care whether we deprecate ZClasses?
--On Mittwoch, 6. April 2005 12:59 Uhr -0500 Ausum Studio <ausum_studio@hotmail.com> wrote:
Is this a kafkanian situation? Are really core developers asking the community to kick a used Zope's feature, saying it's because it's hard to maintain it, and simultaneously to say it's code 'unmaintained and untouched since ages'?
I have not seen any significant changes to ZClasses since Zope 2.4/2.5 or so (that's when I started working for ZC and learned about Zope). Now they broke in Zope 2.8 and kept up the release and maybe only a small number of people have the wisdom to maintain and fix outstanding issues.
As for ZC, IMHO the issue should be treated as a matter of understanding the market rather than achieving a milestone. You created stuff that works in some way or another that people embraced. You also changed your company name to the name of the product of yours that people embraced. And no matter how much hype there is on new trends, you should realize that a song is just a song until the market say it's a hit, and that X3 is that song. Shall you start to put Zope2 into pieces before getting to know you already have a hit? :)
I don't understand what you want to say with that but ZC also lives from the community and the community lives to a certain part of the work of ZC. So is all about giving and taking :-) -aj
Ausum Studio wrote: ...
As for ZC, IMHO the issue should be treated as a matter of understanding the market rather than achieving a milestone. You created stuff that works in some way or another that people embraced. You also changed your company name to the name of the product of yours that people embraced. And no matter how much hype there is on new trends, you should realize that a song is just a song until the market say it's a hit, and that X3 is that song. Shall you start to put Zope2 into pieces before getting to know you already have a hit? :)
Well said. I couldn't agree more. That's why ZC continues to spend lots of time maintaining and enhancing Zope 2. It's why I see many Zope 2 releases ahead and why, every time I speak to large groups of people, I tell people not to feel a need to rush to Zope 3. There is absolutely no intention to make the mistakes of other projects to have an untested new version replace an established new version prematurely. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Yoohoo, ZClasses are not an expert technology to use, they are an introduction to Zope... Just because I use a thing, doesn't mean I can support/maintain a thing. I can read the list, and try to help folks with questions that I've experienced... that's the support that can be offered at my skill level. If that's not enough... fine... drop ZClasses, then DTML (you know, its next)... and all the folks in this boat with me. ZC should decide whether the benefits of ZClasses for low-end developers match against the hurdles to keeping it with the newer Zope releases. If they don't see a need for this skill-level type of tool in Zope's feature list, they will pay down the road... Growth is king, even for Zope, who grew this platform? Growth means newbies, right? What elements got Zope to where it is? Could ZClasses be on that list? Why? And seeing comments like... - "Move to Zope Python Products" - you cant see the skill differences between OOP & Zope's API vs. ZClasses - "Use the Archetypes/CMF/Plone setup" - UML training? the CMF API and Plone underpinnings, easy? - "Maintain it yourself then" - Update very slick code within Zope's flexible and aging API, with ZODB API too? Maintain it...Yeah sure, hows this afternoon. ... just show me how under-represented that beginner and intermediate Zope developers use this list... and then I think, perhaps there aren't any, just me and a few others... and if that's the case, Zope's screwed, and the horse I rode in on. And so here's the confession... "Hello, I'm Jon... I've used Zope for 2 years, and I can't help others program high-level Python OOP tools/platform resources in a propriety web content management server. I only can support their efforts when the occasional mailing list opportunities present themselves." -Jon Cyr, Intermediate Zope Developer cyrj@cyr.info Andreas Jung wrote:
--On Dienstag, 5. April 2005 16:38 Uhr -0400 Jake <jake@zopezone.com> wrote:
And that is probably the best arguement for keeping them around longer.
We should get to the point: if some people depend on ZClasses then they should take over some responsibility in maintaining them in future releases. It can not be that a "feature" regarded as obsolete (from the majority) and almost unmaintained and untouched since ages holds up further releases. I agree with Jim that they should be officially deprecated - means they could be removed in Zope 2.10. We could leave them longer if they should work in further releases without further work. If there are serious problems in further releases with ZClasses holding up a new release we should kick them. So if you depend on ZClasses....learn how they are implemented and maintain them in the future. But from the prospective of limited resource it is not reasonable to spend much time on ZClasses in the future.
-aj
------------------------------------------------------------------------
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.9.4 - Release Date: 4/6/2005
Jonathan Cyr wrote at 2005-4-6 16:06 -0400:
... just show me how under-represented that beginner and intermediate Zope developers use this list... and then I think, perhaps there aren't any, just me and a few others... and if that's the case, Zope's screwed, and the horse I rode in on.
Do not worry too much! Jim proposed to keep ZClasses alive until (at least) Zope 2.10. And he asks whether there is enough interest to keep them longer... If the Zope 2 releases progress in the same speed seen recently, then Zope 2.10 will come in 4 to 6 years. That's a lot of time. Of course, it is planned that future release cycles are much shorter (one release every 6 months) but I do not yet buy that this will indeed happen. Almost all releases were planned much earlier than they happened. And, we can keep ZClasses alive, at least until the next major "Persistency" shakeup (after Jim made them working again for the current "Persistency" shakeup) -- even when they are no longer in the core. In fact, I have had ten times more problems with Archetypes (which I use now) than with ZClasses (which I used formerly). It is true (and sad) that there are no unit tests for ZClasses but ZClasses just broke twice in the past across releases and the community quickly found workarounds. These fixes were found much faster than those for the security problems which were introduced from time to time into Zope through security shakeups -- despite the fact that there are unit tests for the security subsystem. Thus, the right approach (in my view) is that all users of ZClasses tell Jim, that ZClasses are used and interesting. ZClasses may nevertheless get deprecated but probably kept longer then Zope 2.10 unless they cause major problems. For new projects, you should investigate the new options. Product development will get much simpler with Zope3 technology (and its schemas and views). Currently, there is no TTW ("Through The Web") development in Zope3 land, but that is planned. In about 2 to 4 years, we may have new ZClass like functionality implemented with Zope3 technology. And I am quite confident that the old ZClasses will live til then...
And so here's the confession... "Hello, I'm Jon... I've used Zope for 2 years, and I can't help others program high-level Python OOP tools/platform resources in a propriety web content management server. I only can support their efforts when the occasional mailing list opportunities present themselves."
That's fine. Continue with this support! Do not worry too much about ZClasses. They will stay for a significant time because Jim plans to take the next major hurdle (thank you, Jim!). After that, probably only small changes will be necessary -- as in the past. We, the ZClass users, can manage these minor changes -- as we did in the past. -- Dieter
I think people on this list need to realize that eventually, the direction of any significantly large Open Source project is hijacked by the relatively small number of people actually doing the work. The reasons for this are many-fold, but, normally come down to a lack of communication between the developers and the users, which is realized in a lack of understanding by the developers of what the users want. This for the most part isn't generally a problem, until, the developers start to do things "for the user's own good", like remove features that are "kludgey", or a "hack", or <insert some other reason>, which generally means either noone wants to work on it, or some other change caused it to break, and noone wants to fix it. Now to the credit of the Zope guys, they actually poll the users to find out, rather than just announce the demise of something. However, in general once you add a feature, you can be guaranteed, that somewhere, someone is using it, so removing it will always cause a problem. So there will always be an uproar when you poll. You're never going to be able to reduce the feature set between point releases without upsetting some group of people. So why don't we stop all this nonsense now, and just agree, that you're never going to do that d8) You have Zope 3 to remove all the stuff you hate d8) In my opinion if you change something, it's your responsibility to fix the resulting breakage. That's part of your responsibiliity to the rest of the community (i.e. the [mostly non-paying] customers). If you don't think you have this responsibility to us, then you should work on your own version of Zope, where you're not impacting anyone else. For the record, I hate ZClasses... d8) -- Andrew Milton akm@theinternet.com.au
Andrew Milton wrote:
I think people on this list need to realize that eventually, the direction of any significantly large Open Source project is hijacked by the relatively small number of people actually doing the work.
The reasons for this are many-fold, but, normally come down to a lack of communication between the developers and the users, which is realized in a lack of understanding by the developers of what the users want.
This for the most part isn't generally a problem, until, the developers start to do things "for the user's own good", like remove features that are "kludgey", or a "hack", or <insert some other reason>, which generally means either noone wants to work on it, or some other change caused it to break, and noone wants to fix it.
Now to the credit of the Zope guys, they actually poll the users to find out, rather than just announce the demise of something. However, in general once you add a feature, you can be guaranteed, that somewhere, someone is using it, so removing it will always cause a problem. So there will always be an uproar when you poll.
You're never going to be able to reduce the feature set between point releases without upsetting some group of people. So why don't we stop all this nonsense now, and just agree, that you're never going to do that d8) You have Zope 3 to remove all the stuff you hate d8)
In my opinion if you change something, it's your responsibility to fix the resulting breakage. That's part of your responsibiliity to the rest of the community (i.e. the [mostly non-paying] customers). If you don't think you have this responsibility to us, then you should work on your own version of Zope, where you're not impacting anyone else.
For the record, I hate ZClasses... d8)
I wish Terri Shiavo had as much compassion as ZClasses.
David H escribió:
Andrew Milton wrote:
I think people on this list need to realize that eventually, the direction of any significantly large Open Source project is hijacked by the relatively small number of people actually doing the work.
The reasons for this are many-fold, but, normally come down to a lack of communication between the developers and the users, which is realized in a lack of understanding by the developers of what the users want.
This for the most part isn't generally a problem, until, the developers start to do things "for the user's own good", like remove features that are "kludgey", or a "hack", or <insert some other reason>, which generally means either noone wants to work on it, or some other change caused it to break, and noone wants to fix it.
Now to the credit of the Zope guys, they actually poll the users to find out, rather than just announce the demise of something. However, in general once you add a feature, you can be guaranteed, that somewhere, someone is using it, so removing it will always cause a problem. So there will always be an uproar when you poll.
You're never going to be able to reduce the feature set between point releases without upsetting some group of people. So why don't we stop all this nonsense now, and just agree, that you're never going to do that d8) You have Zope 3 to remove all the stuff you hate d8)
In my opinion if you change something, it's your responsibility to fix the resulting breakage. That's part of your responsibiliity to the rest of the community (i.e. the [mostly non-paying] customers). If you don't think you have this responsibility to us, then you should work on your own version of Zope, where you're not impacting anyone else.
For the record, I hate ZClasses... d8)
I wish Terri Shiavo had as much compassion as ZClasses.
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Perhaps a unfortunated comment
<flame> What gives us the right to dictate what features these people give up their time to work on? Sure, Zope (the company) pays some, but others seem to do it for no direct reward, other than the Zope program. <end flame> I admire these people, I have no idea what goes through Zope, though I might look at fixing some bugs and submitting patches to see what's involved. If you love the feature so much, either make it work yourself, or pay someone to. I do sympathise those who have spent time creating and maintaining solutions based on ZClasses, and I hope someone comes up with a system to export them to a product. I started with python scripts and then a product. Basic products are simple and development can be quite fast with refreshing turned on. -- Phillip Hutchings http://www.sitharus.com/ sitharus@gmail.com / sitharus@sitharus.com
Well said. I mostly agree, however, there needs to be a balance. We are introducing a process for orderly deprecation of features. I hope it works. It's mainly useful for changes that are straightforward to recover from. We have to balance lots of different factors taking into account *everybodies* interests, the best we can *together*. Jim Andrew Milton wrote:
I think people on this list need to realize that eventually, the direction of any significantly large Open Source project is hijacked by the relatively small number of people actually doing the work.
The reasons for this are many-fold, but, normally come down to a lack of communication between the developers and the users, which is realized in a lack of understanding by the developers of what the users want.
This for the most part isn't generally a problem, until, the developers start to do things "for the user's own good", like remove features that are "kludgey", or a "hack", or <insert some other reason>, which generally means either noone wants to work on it, or some other change caused it to break, and noone wants to fix it.
Now to the credit of the Zope guys, they actually poll the users to find out, rather than just announce the demise of something. However, in general once you add a feature, you can be guaranteed, that somewhere, someone is using it, so removing it will always cause a problem. So there will always be an uproar when you poll.
You're never going to be able to reduce the feature set between point releases without upsetting some group of people. So why don't we stop all this nonsense now, and just agree, that you're never going to do that d8) You have Zope 3 to remove all the stuff you hate d8)
In my opinion if you change something, it's your responsibility to fix the resulting breakage. That's part of your responsibiliity to the rest of the community (i.e. the [mostly non-paying] customers). If you don't think you have this responsibility to us, then you should work on your own version of Zope, where you're not impacting anyone else.
For the record, I hate ZClasses... d8)
-- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
+-------[ Jim Fulton ]---------------------- | Well said. | | I mostly agree, however, there needs to be a balance. We are | introducing a process for orderly deprecation of features. I hope | it works. It's mainly useful for changes that are straightforward | to recover from. We have to balance lots of different factors | taking into account *everybodies* interests, the best we can | *together*. Indeed. You would probably reach more people via the zope.org website, than via the mailing list. That would give you a bigger value of "everybody". Perhaps a questionnaire or survey arrangement, so you can find out how people are using Zope. You could release it quarterly or six-monthly or something so you can see how things are trending over time. This would allow you to gauge the size of subsets of the community and to predict the likely fallout of removing something d8) You could also get better understanding of other data, e.g. what platforms zope is running on in what numbers, as opposed to just the raw download statistics. At the very least you could find out their interests d8) Perhaps it's something one of the non-ZC sites would want to host? -- Andrew Milton akm@theinternet.com.au
On Wednesday 06 April 2005 16:52, Dieter Maurer wrote:
For new projects, you should investigate the new options. Product development will get much simpler with Zope3 technology (and its schemas and views). Currently, there is no TTW ("Through The Web") development in Zope3 land, but that is planned. In about 2 to 4 years, we may have new ZClass like functionality implemented with Zope3 technology. And I am quite confident that the old ZClasses will live til then...
Note that I prototyped such functionality a couple years ago. One could create TTW (Persistent) schemas and then declare a Content Component Definition based on this schema. People could then create instances of those content components. The Content Component Definition utility took care of doing all the security and basic menu/view setup. One can then write views and adapters for the content component to give it functionality. Unfortunately, persistent schemas got broken at some point, so the code is not that useful anymore. I really need to get together with Jim and force him to fix the problem with me, since I constantly forget what the problem is. ;-) Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Thank You for giving me a timeframe for this stuff. 4 to 6 years is indeed a long time. That would, in effect triple the lifespan of my project, and be far more reasonable. It was the "yeah, dump it today" remarks that set me off. These remarks are shortsighted at best, and harmful to Zope's PR at worst. Thanks for the response, I will contribute where I can. -Jon Dieter Maurer wrote:
Jonathan Cyr wrote at 2005-4-6 16:06 -0400:
... just show me how under-represented that beginner and intermediate Zope developers use this list... and then I think, perhaps there aren't any, just me and a few others... and if that's the case, Zope's screwed, and the horse I rode in on.
Do not worry too much!
Jim proposed to keep ZClasses alive until (at least) Zope 2.10. And he asks whether there is enough interest to keep them longer...
If the Zope 2 releases progress in the same speed seen recently, then Zope 2.10 will come in 4 to 6 years. That's a lot of time. Of course, it is planned that future release cycles are much shorter (one release every 6 months) but I do not yet buy that this will indeed happen. Almost all releases were planned much earlier than they happened.
And, we can keep ZClasses alive, at least until the next major "Persistency" shakeup (after Jim made them working again for the current "Persistency" shakeup) -- even when they are no longer in the core.
In fact, I have had ten times more problems with Archetypes (which I use now) than with ZClasses (which I used formerly). It is true (and sad) that there are no unit tests for ZClasses but ZClasses just broke twice in the past across releases and the community quickly found workarounds. These fixes were found much faster than those for the security problems which were introduced from time to time into Zope through security shakeups -- despite the fact that there are unit tests for the security subsystem.
Thus, the right approach (in my view) is that all users of ZClasses tell Jim, that ZClasses are used and interesting. ZClasses may nevertheless get deprecated but probably kept longer then Zope 2.10 unless they cause major problems.
For new projects, you should investigate the new options. Product development will get much simpler with Zope3 technology (and its schemas and views). Currently, there is no TTW ("Through The Web") development in Zope3 land, but that is planned. In about 2 to 4 years, we may have new ZClass like functionality implemented with Zope3 technology. And I am quite confident that the old ZClasses will live til then...
And so here's the confession... "Hello, I'm Jon... I've used Zope for 2 years, and I can't help others program high-level Python OOP tools/platform resources in a propriety web content management server. I only can support their efforts when the occasional mailing list opportunities present themselves."
That's fine. Continue with this support!
Do not worry too much about ZClasses. They will stay for a significant time because Jim plans to take the next major hurdle (thank you, Jim!). After that, probably only small changes will be necessary -- as in the past. We, the ZClass users, can manage these minor changes -- as we did in the past.
--On Mittwoch, 6. April 2005 16:06 Uhr -0400 Jonathan Cyr <cyrj@cyr.info> wrote:
Yoohoo,
ZClasses are not an expert technology to use, they are an introduction to Zope... Just because I use a thing, doesn't mean I can support/maintain a thing. I can read the list, and try to help folks with questions that I've experienced... that's the support that can be offered at my skill level.
There are better ways to learn Zope than by using ZClasses. They should no longer be mentioned e.g. in the Zope Book.
If that's not enough... fine... drop ZClasses, then DTML (you know, its next)... and all the folks in this boat with me.
That's nonsense. Open-source is a giving and taking. Ok, you can demand something *but* the resources of the people giving something to you are limited and restricted by several constraints (company needs, personal time etc.). As said a bunch of times earlier ZClasses help up the 2.8 release. Every software has its life-cycle it is sometimes a good thing to drop old things over board *if* they tend to cause serious problems. This is here the case. So my proposal was to deprecate them officially in 2.8 with the possibility to kick them in 2.10 or later. Read carefully ("possibility"). Means if they do not hurt in 2.10 or 2.11 then could stay but ZClasses could be removed if major resources would be necessary to fix them.
ZC should decide whether the benefits of ZClasses for low-end developers match against the hurdles to keeping it with the newer Zope releases. If they don't see a need for this skill-level type of tool in Zope's feature list, they will pay down the road... Growth is king, even for Zope, who grew this platform? Growth means newbies, right? What elements got Zope to where it is? Could ZClasses be on that list? Why?
And seeing comments like...
- "Move to Zope Python Products" - you cant see the skill differences between OOP & Zope's API vs. ZClasses
- "Use the Archetypes/CMF/Plone setup" - UML training? the CMF API and Plone underpinnings, easy?
If you are a somewhat clever (I assume you are) than you should be able to adopt these technologies with a resonable amout of time. Using AT as an example is easy and *more* straight forward than using ZClasses where you can run against the wall very easily. From the programmers experiences these frameworks are the future and definitely not ZClasses.
- "Maintain it yourself then" - Update very slick code within Zope's flexible and aging API, with ZODB API too? Maintain it...Yeah sure, hows this afternoon.
See above....if you have a need or interest in keep ZClasses you could pay Jim some USD to fix ZClasses for you. I don't see it as a responsibility to provide backward-compatibility for all and everything for ages. It would be nice to have that *but* our resources are limited - they are especially limited because I see little interest of the community helping out in Zope areas where work must be done. Means the active people in the Zope community have/try to do help out in many fields restricting their time from serious Zope work. -aj
Jonathan Cyr wrote:
Yoohoo,
ZClasses are not an expert technology to use, they are an introduction to Zope... Just because I use a thing, doesn't mean I can support/maintain a thing.
Exactly. I want you to use Zope even if you aren't in a position to maintain it yourself.
I can read the list, and try to help folks with questions that I've experienced... that's the support that can be offered at my skill level.
Which is extremely valuable.
If that's not enough... fine... drop ZClasses, then DTML (you know, its next)... and all the folks in this boat with me.
(There are no plans to deprecate DTML. It is even supported in Zope 3.)
ZC should decide whether the benefits of ZClasses for low-end developers match against the hurdles to keeping it with the newer Zope releases. If they don't see a need for this skill-level type of tool in Zope's feature list, they will pay down the road... Growth is king, even for Zope, who grew this platform? Growth means newbies, right? What elements got Zope to where it is? Could ZClasses be on that list? Why?
Vey well said. I think this is, but should not be underestimated. This is something I think about a lot. I think Zope needs to support developers and non developers. Zope 2 was weak in supporting developers. Over the years, new techniques and technologies have evolved to make Zope development better for proffessional developers, but we still need the non-developers.
And seeing comments like...
- "Move to Zope Python Products" - you cant see the skill differences between OOP & Zope's API vs. ZClasses
- "Use the Archetypes/CMF/Plone setup" - UML training? the CMF API and Plone underpinnings, easy?
- "Maintain it yourself then" - Update very slick code within Zope's flexible and aging API, with ZODB API too? Maintain it...Yeah sure, hows this afternoon.
... just show me how under-represented that beginner and intermediate Zope developers use this list... and then I think, perhaps there aren't any, just me and a few others... and if that's the case, Zope's screwed, and the horse I rode in on.
:) This list is for you. While you shouldn't have to maintain Zope yourself, you *do* need to be vocal about what you want. (Of course, at some point, work needs to get paid for. If someone wants a new feature that the developers don't want to develop out of the goodness of their hearts or even an old feature that no one wants to maintain, someone may have to be willing to fund some development. I'm not asking for this in this case.)
And so here's the confession... "Hello, I'm Jon... I've used Zope for 2 years, and I can't help others program high-level Python OOP tools/platform resources in a propriety web content management server. I only can support their efforts when the occasional mailing list opportunities present themselves."
And that support is greatly appreciated! Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton said:
(There are no plans to deprecate DTML. It is even supported in Zope 3.)
That is the best news I have heard all day (although, it is early). Jake -- Zoping for the rest of us http://www.ZopeZone.com
Jake wrote:
Jim Fulton said:
(There are no plans to deprecate DTML. It is even supported in Zope 3.)
That is the best news I have heard all day (although, it is early).
I will be selling black flags for the mourning of a missed opportunity... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Hi Chris, Chris Withers wrote:
(There are no plans to deprecate DTML. It is even supported in Zope 3.)
That is the best news I have heard all day (although, it is early).
I will be selling black flags for the mourning of a missed opportunity...
With or without a circled "A"? ;-) -- Regards, PhilK Email: phil@xfr.co.uk / Voicemail & Facsimile: 07092 070518 "it's very hard to talk quantum using a language originally designed to tell other monkeys where the ripe fruit is" - Lu-Tze
Chris Withers <chris@simplistix.co.uk> wrote:
Jake wrote:
Jim Fulton said:
(There are no plans to deprecate DTML. It is even supported in Zope 3.)
That is the best news I have heard all day (although, it is early).
I will be selling black flags for the mourning of a missed opportunity...
DTML is very nice for some things. And for beginners. Only the magic namespaces of DTML are bad, and those are gone in Zope 3. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Florent Guillaume wrote:
Chris Withers <chris@simplistix.co.uk> wrote:
Jake wrote:
Jim Fulton said:
(There are no plans to deprecate DTML. It is even supported in Zope 3.)
That is the best news I have heard all day (although, it is early).
I will be selling black flags for the mourning of a missed opportunity...
DTML is very nice for some things. And for beginners.
Only the magic namespaces of DTML are bad, and those are gone in Zope 3.
I wish they were gone, but they are still there. Someday, I'd like to se a TALES-based DTML, but I doubt I'll ever have time to do it. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
I wish they were gone, but they are still there. Someday, I'd like to se a TALES-based DTML, but I doubt I'll ever have time to do it.
You know that means you want to deprecate it really ;-) I still maintaining ofrcing users to learn two templating languages, one of which is one of the oldest things in the whole framework, is pretty cruel, but then we as a community, do seem to like inflicting new languages on our end users *grinz* Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Andreas Jung wrote:
--On Dienstag, 5. April 2005 16:38 Uhr -0400 Jake <jake@zopezone.com> wrote:
And that is probably the best arguement for keeping them around longer.
We should get to the point: if some people depend on ZClasses then they should take over some responsibility in maintaining them in future releases.
Be careful here. While there is value in deciding priorities based on willingness of people to help. We want people to use Zope *even* if they can't maintain it. It would be a huge mistake to gibe people the impression that they should only use Zope if they are prepared to maintain it themselves. In other words, the availability of volunteers is a good criteria for selecting *new* features.
It can not be that a "feature" regarded as obsolete (from the majority) and almost unmaintained and untouched since ages holds up further releases.
It is being maintained now. I don't think we can choose not to maintain such an important feature. I agree that new features should only be done of there are developers willing to do them.
I agree with Jim that they should be officially deprecated - means they could be removed in Zope 2.10.
Whoa, I'm not advocating that. I was asking if anyone cared. I strongly suspected that there would be people who did care. I've gotten a lot of grief because of the effort I've been putting into getting them to work with Zope 2.8 and the effect that that has had on the 2.8 schedule. Many active Zope developers are (understandbly) dismissive of ZClasses, but I think we can't ignore the many people who depend on them. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote:
I've gotten a lot of grief because of the effort I've been putting into getting them to work with Zope 2.8 and the effect that that has had on the 2.8 schedule. Many active Zope developers are (understandbly) dismissive of ZClasses, but I think we can't ignore the many people who depend on them.
I think this course of action leads to misinforming new users that ZClasses are a "good thing". If ZClasses really must stay around, then put them in a big box labelled "some people like these, but the community as a whole recommends against them", which seems to be the consensus here. I think ZPT and python scripts are much more useful tools for newbies who will often enter with a scripting rather than OO frame of mind. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Jim Fulton wrote:
I think ZPT and python scripts are much more useful tools for newbies who will often enter with a scripting rather than OO frame of mind.
Wouldn't that be ZPT and adapters ;-) -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science
Chris Withers wrote at 2005-4-7 13:22 +0100:
... but the community as a whole recommends against them", which seems to be the consensus here.
A funny definition of consensus... It may be the majority opinion but it definitely is not "consensus"... -- Dieter
(Tue, Apr 05, 2005 at 06:46:23PM -0400) zope-request@zope.org wrote/schrieb/egrapse:
From: Dieter Maurer <dieter@handshake.de>: "ZClasses" feature prominently in the Zope book.
Seems they are more recommended than the new development paradigm (which does not yet feature at all in the Zope book).
I don't know if I'm living under a rock or something, but I'm using Zope on and off since about 2.5.1, and I've barely heard about archetypes. So far I did not come across a simple introduction, tutorial, or even explanation of them. Of course I haven't searched, but I guess that is the point of Dieters remark. ZClasses, external methods and to some extend Python products byte you the moment you get to the Zope documentation. The "new stuff" is that stuff I hear the buzzwords flying around, but once I touch something of it, I'm lost pretty fast. If something is the "new and recommended way" of doing things, it should be first place in the docs. The "Zope Bible" has Python products before other stuff IIRC, good. If the "new stuff" is so great and easy to use, it should also be easy to put some documentation of it in Chapter 2 or 3 of whatever the Zope Docs will be. As for the question of depreciating ZClasses: I had started out with ZClasses once, got to know the limitations and am now doing Python products. I've learned a lot using ZClasses, as one can jumble and play around with object orientation much easier. Python products offer a much steeper wall, there is much more that has to be just right just to get started. So if the "new stuff" offers that easy intro playground and has adequate docs, then replace ZClasses. And btw, keep up the good work, thanks! Sascha -- http://betabug.ch/blogs/ch-athens
I don't know if I'm living under a rock or something, but I'm using Zope on and off since about 2.5.1, and I've barely heard about archetypes. So far I did not come across a simple introduction, tutorial, or even explanation of them.
The "new stuff" mentioned on this thread is the zope 3 component architecture. With zope 2.8 it will be possible to start using the same ideas (although not 100% compatible). This will definitely be the new recommended way to do development, if not in 2.8, then in 2.9, which hopefully will have great compatibilty with zope3. As mentioned, it is very important that the documentation get updated to reflect this. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Dieter Maurer wrote:
Lennart Regebro wrote at 2005-4-5 11:48 +0200:
On the Paris sprint, one thing that was noted was how ironic it was that the release of 2.8, which includes support for the new recommended development paradigm, was held up becuase we neeeded to support an old non-recommended one. :-)
"ZClasses" feature prominently in the Zope book.
That should probably be fixed.
Seems they are more recommended than the new development paradigm (which does not yet feature at all in the Zope book).
The new developement paradigm is featured prominantly in 2 new books. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote at 2005-4-7 05:50 -0400:
Dieter Maurer wrote: ...
"ZClasses" feature prominently in the Zope book.
That should probably be fixed.
Seems they are more recommended than the new development paradigm (which does not yet feature at all in the Zope book).
The new developement paradigm is featured prominantly in 2 new books.
When will they feature in *the* "Zope Book"? There are Zope beginners that will not start with a Zope3 book -- at least not yet. -- Dieter
Dieter Maurer wrote:
When will they feature in *the* "Zope Book"?
Which "The Zope Book" are you referring to? The 2.6 one on Zope.org? The 2.7 one on Plope.com? The 3.whatever one somewhere-I-don't-know? It's the age old documentation problem coming back to bite us again :-S cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Apr 8, 2005 8:48 AM, Chris Withers <chris@simplistix.co.uk> wrote:
Dieter Maurer wrote:
When will they feature in *the* "Zope Book"?
Which "The Zope Book" are you referring to?
The 2.6 one on Zope.org? The 2.7 one on Plope.com? The 3.whatever one somewhere-I-don't-know?
I would expect it to be "featured", that is mentioned as a recommended practice, in a Zope2.9 book, should one appear. I also thonk that with 2.8 a 2.8 book should be released, which main feature could be to move the ZClass part to an appendix. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On Fri, Apr 08, 2005 at 10:59:46AM +0200, Lennart Regebro wrote:
On Apr 8, 2005 8:48 AM, Chris Withers <chris@simplistix.co.uk> wrote:
Dieter Maurer wrote:
When will they feature in *the* "Zope Book"?
Which "The Zope Book" are you referring to?
The 2.6 one on Zope.org? The 2.7 one on Plope.com? The 3.whatever one somewhere-I-don't-know?
I would expect it to be "featured", that is mentioned as a recommended practice, in a Zope2.9 book, should one appear. I also thonk that with 2.8 a 2.8 book should be released, which main feature could be to move the ZClass part to an appendix.
I would love that. But in the present day, we haven't even finished the 2.7 book. I suppose we could just change the book's release number from 2.7 to 2.8 and hope that's adequate ;-) But that leaves unanswered questions - should we document the Five stuff at all, and if so, how? The primary problem with the Zope Book is still the relative scarcity of resources (i.e. editors with time to work on it). The secondary problem with the Zope Book is that it's showing its age: the choice and organization of topics is IMHO less than ideal, but that can't be sufficiently addressed on a chapter-by-chapter basis, one needs to have a good overview of the whole project. This vastly increases the scope of the task. Sadly I can't see the status quo changing unless somebody wants to invest sufficient money in the project so that some of the independent contractors involved could schedule work on the book as an actual paying job. Hopefully one of two things will happen: * I will be proven wrong, or * such money will materialize somehow :-) -- Paul Winkler http://www.slinkp.com
I don't think anyone has given much thought to actually documenting all these nice nifty features in 2.9. Which is no change from the norm, and it will be a fairly organic process again. I hate it, but whatever. - C On Fri, 2005-04-08 at 11:22, Paul Winkler wrote:
On Fri, Apr 08, 2005 at 10:59:46AM +0200, Lennart Regebro wrote:
On Apr 8, 2005 8:48 AM, Chris Withers <chris@simplistix.co.uk> wrote:
Dieter Maurer wrote:
When will they feature in *the* "Zope Book"?
Which "The Zope Book" are you referring to?
The 2.6 one on Zope.org? The 2.7 one on Plope.com? The 3.whatever one somewhere-I-don't-know?
I would expect it to be "featured", that is mentioned as a recommended practice, in a Zope2.9 book, should one appear. I also thonk that with 2.8 a 2.8 book should be released, which main feature could be to move the ZClass part to an appendix.
I would love that. But in the present day, we haven't even finished the 2.7 book. I suppose we could just change the book's release number from 2.7 to 2.8 and hope that's adequate ;-)
But that leaves unanswered questions - should we document the Five stuff at all, and if so, how?
The primary problem with the Zope Book is still the relative scarcity of resources (i.e. editors with time to work on it).
The secondary problem with the Zope Book is that it's showing its age: the choice and organization of topics is IMHO less than ideal, but that can't be sufficiently addressed on a chapter-by-chapter basis, one needs to have a good overview of the whole project. This vastly increases the scope of the task.
Sadly I can't see the status quo changing unless somebody wants to invest sufficient money in the project so that some of the independent contractors involved could schedule work on the book as an actual paying job. Hopefully one of two things will happen:
* I will be proven wrong, or * such money will materialize somehow :-)
Chris McDonough wrote:
I don't think anyone has given much thought to actually documenting all these nice nifty features in 2.9. Which is no change from the norm, and it will be a fairly organic process again. I hate it, but whatever.
- C
Speaking of which, and being one of the people that promised to deliver but has not done so 100% yet, is it possible to checkout the Zope Book from cvs or svn? That'd help a lot in terms of incrementally adding stuff, at least for me. Thanks, /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. "...and click? damn, I need to kill -9 Word again..." - b using macosx
No, sorry. THe canonical version is on the web. - C On Tue, 2005-04-12 at 04:10, Dario Lopez-Kästen wrote:
Chris McDonough wrote:
I don't think anyone has given much thought to actually documenting all these nice nifty features in 2.9. Which is no change from the norm, and it will be a fairly organic process again. I hate it, but whatever.
- C
Speaking of which, and being one of the people that promised to deliver but has not done so 100% yet, is it possible to checkout the Zope Book from cvs or svn?
That'd help a lot in terms of incrementally adding stuff, at least for me.
Thanks,
/dario
On Apr 8, 2005 5:22 PM, Paul Winkler <pw_lists@slinkp.com> wrote:
But that leaves unanswered questions - should we document the Five stuff at all, and if so, how?
Well, the Five stuff is a subset of the Zope3 stuff, with way too much Zope2 stuff still necessary. The idea is that this should change quite rapidly and get more and more Zope3-ish and become less and less of a subset. So it may be that documenting it is a bit of a waste of time. I think the most realistic part is to rename the 2.7 book to 2.8, move ZClasses and DTML last, note that 2.8 includes some Zope3 support but don't document it. Then we'll concentrate on getting 2.9s Zope3 support to be more Zope3-ish, and documenting the differences into a Zope2.9 book. ;) I don't have an overview of what needs to be done on the Zope book in general though. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On Fri, Apr 08, 2005 at 05:41:30PM +0200, Lennart Regebro wrote:
On Apr 8, 2005 5:22 PM, Paul Winkler <pw_lists@slinkp.com> wrote:
But that leaves unanswered questions - should we document the Five stuff at all, and if so, how?
Well, the Five stuff is a subset of the Zope3 stuff, with way too much Zope2 stuff still necessary. The idea is that this should change quite rapidly and get more and more Zope3-ish and become less and less of a subset.
So it may be that documenting it is a bit of a waste of time. I think the most realistic part is to rename the 2.7 book to 2.8, move ZClasses and DTML last, note that 2.8 includes some Zope3 support but don't document it.
OK, but there should at least be a pointer to something to read for people wanting to get started with 2.8.0/Five. I haven't yet looked at any of the Five stuff. Is there at least a README? :)
Then we'll concentrate on getting 2.9s Zope3 support to be more Zope3-ish, and documenting the differences into a Zope2.9 book. ;)
Yes, I'm sure we will ;-)
I don't have an overview of what needs to be done on the Zope book in general though.
Well, the chapter-by-chapter editing is still not done. See http://plope.com/Books/zb_signup for an overview of the known tasks to be done. -- Paul Winkler http://www.slinkp.com
On Apr 8, 2005 5:59 PM, Paul Winkler <pw_lists@slinkp.com> wrote:
OK, but there should at least be a pointer to something to read for people wanting to get started with 2.8.0/Five. I haven't yet looked at any of the Five stuff. Is there at least a README? :)
Sure. I don't guarantee that it's remotely relevant, however. :-)
Well, the chapter-by-chapter editing is still not done. See http://plope.com/Books/zb_signup for an overview of the known tasks to be done.
OK, but that's better than expected, I'd say. :) It sais "Finished" on a whole bunch of chapters. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On Fri, Apr 08, 2005 at 06:06:57PM +0200, Lennart Regebro wrote:
On Apr 8, 2005 5:59 PM, Paul Winkler <pw_lists@slinkp.com> wrote:
Well, the chapter-by-chapter editing is still not done. See http://plope.com/Books/zb_signup for an overview of the known tasks to be done.
OK, but that's better than expected, I'd say. :) It sais "Finished" on a whole bunch of chapters.
Yep! But only about half. Current stats for anyone who cares: Finished 15 In Progress 12 Not Started 1 Unclaimed 4 -- Paul Winkler http://www.slinkp.com
On Friday 08 April 2005 11:22, Paul Winkler wrote:
The primary problem with the Zope Book is still the relative scarcity of resources (i.e. editors with time to work on it).
The secondary problem with the Zope Book is that it's showing its age: the choice and organization of topics is IMHO less than ideal, but that can't be sufficiently addressed on a chapter-by-chapter basis, one needs to have a good overview of the whole project. This vastly increases the scope of the task.
Note that my Zope 3 book is published under CC license. I could ask SAMS whether it would be okay to include parts (with proper reference and copyright notice) in the online version of the Zope 2 book. That will not document Five, but some of the component architecture. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Lennart Regebro wrote at 2005-4-8 10:59 +0200:
... On Apr 8, 2005 8:48 AM, Chris Withers <chris@simplistix.co.uk> wrote: ...
Which "The Zope Book" are you referring to?
The 2.6 one on Zope.org? The 2.7 one on Plope.com? The 3.whatever one somewhere-I-don't-know?
I would expect it to be "featured", that is mentioned as a recommended practice, in a Zope2.9 book, should one appear. I also thonk that with 2.8 a 2.8 book should be released, which main feature could be to move the ZClass part to an appendix.
Indead, something along this line... -- Dieter
On Fri, Apr 08, 2005 at 06:58:31PM +0200, Dieter Maurer wrote:
Lennart Regebro wrote at 2005-4-8 10:59 +0200:
... On Apr 8, 2005 8:48 AM, Chris Withers <chris@simplistix.co.uk> wrote: ...
Which "The Zope Book" are you referring to?
The 2.6 one on Zope.org? The 2.7 one on Plope.com? The 3.whatever one somewhere-I-don't-know?
I would expect it to be "featured", that is mentioned as a recommended practice, in a Zope2.9 book, should one appear. I also thonk that with 2.8 a 2.8 book should be released, which main feature could be to move the ZClass part to an appendix.
Indead, something along this line...
Considering that we still have not finished the "2.7" edition of the book, I find it very unlikely that we will manage to get something out in sync with the first zope 2.8 release. Anyone who wishes to help us edit the book is encouraged to visit http://plope.com/Books/zb_signup -- Paul Winkler http://www.slinkp.com
Lennart Regebro wrote:
On the Paris sprint, one thing that was noted was how ironic it was that the release of 2.8, which includes support for the new recommended development paradigm, was held up becuase we neeeded to support an old non-recommended one. :-)
It boils down to backward compatibility. Backward compatibility is important. People aren't going to use our platform if it keeps changing. in backward incompatible ways without reletively smooth transition tools. We can't simply drop such a critical feature just because we don't want to maintain it. Heck, I'd love to drop version support from ZODB, but I'm not going to until I can offer a replacement to the people who depend on versions today.
Anyway, my main question is: You who are using ZClasses, can't you just stay on Zope2.8 or 2.9, if Zope 2.10 would not contain ZClass support? The main features of 2.8 is support for the component architecture,
For many people, the main features of 2.8 are multi-version concurrency control and better garbage collection.
and for zope 2.9 and 2.10 this will be even more true: there will most likely be very few new features besides this.
I wouldn't assume that. People continue to do interesting things on this platform. In any case, if we put people in the place where they couldn't (in a practical, rather than theoretical sense) migrate from a particular version, then we'd have to consider maintaining that version longer that we otherwise would, if only to give people bug fixes (especially security fixes).
With 2.9 or 2.10 the idea is that you can use both ZClasses, *and* write products that work under Zope3. I'm not even sure there will be a 2.10, and in any case you won't really have much need of it.
I'd be very surprised if there was not a Zope 2.10, or even a Zope 2.11. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
participants (24)
-
Andreas Jung -
Andrew Milton -
Arenz, Ralph -
Ausum Studio -
Chris McDonough -
Chris Withers -
Dario Lopez-Kästen -
David H -
Dieter Maurer -
Florent Guillaume -
Garito -
Jake -
Jens Vagelpohl -
Jim Fulton -
Jonathan Cyr -
Lennart Regebro -
Max M -
Paul Winkler -
Philip Kilner -
Phillip Hutchings -
Sascha Welter -
Simon Michael -
Stephan Richter -
Tres Seaver