Zope 3.4.0 candidate 1 Released
January 31, 2008 - The Zope 3 development team announces the Zope 3.4.0c1 release. This release is the first release candidate for Zope 3.4.0. It was preceeded by an early beta 2 release back in November, 2007. Zope 3.4 introduces support for binary large objects in the ZODB, and provides a new postprocessing hook for publishing results. Many of the packages also provide small feature improvements that are too numerous to list at this point. Packages and Eggs ----------------- Since the first Zope 3.4 alpha and beta releases, we have finished the transition to a completely egg-based system. This largely means that most Zope 3 developers do not use the classic Zope 3 tar ball release anymore. However, for your convenience, the Zope 3 developers will provide the classic Zope 3 tar ball releases for at least the 3.4 series and probably for 3.5 as well. So how are Zope 3 applications built using only eggs? The Known Good Set (KGS) ~~~~~~~~~~~~~~~~~~~~~~~~ The known good set -- or in short KGS -- is a package index that derives from the official Python Package Index (PyPI) and thus contains all available packages in the Python world. But for a controlled set of packages, only certain versions that are known to work together are available. The list of controlled packages and their versions for Zope 3.4 can be found at the index page [1]_. The index can be used in several ways -- described here for `buildout`-based projects. The easiest method is to specify the index option in your ``buildout.cfg`` file:: [buildout] index = http://download.zope.org/zope3.4 ... You can also "nail" the versions by downloading the versions [2]_ and insert them as follows: [buildout] versions = versions ... [versions] zope.interface = 3.4.0 ... ``zopeproject`` Project Builder ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Philipp von Weitershausen has developed a package called `zopeproject` to quickly setup the boilerplate for any Zope 3 based project. Ample documentation is provided at the `zopeproject` home page [3]_. `zopeproject` uses Paste or ZDaemon to create a working server. Here are the necessary commands to get a project started:: $ easy_install zopeproject $ zopeproject HelloWorld $ cd HelloWorld $ bin/helloworld-ctl foreground Demo Packages ~~~~~~~~~~~~~ At this point, there is no demo package demonstrating a simple Zope 3 application setup. (I hope one gets developed before Zope 3.4.0 final.) However, the ``z3c.formdemo`` package can be used as a fairly minimal setup. To get started with it, do the following:: $ svn co svn://svn.zope.org/repos/main/z3c.formdemo/tags/1.5.1 formdemo $ cd formdemo $ python bootstrap.py $ ./bin/buildout -v $ ./bin/demo fg .. [1] http://download.zope.org/zope3.4/controlled-packages.cfg .. [2] http://download.zope.org/zope3.4/versions.cfg .. [3] http://pypi.python.org/pypi/zopeproject What is Zope 3? --------------- Zope 3 is a web application server that continues to build on the heritage of Zope. It was rewritten from scratch based on the latest software design patterns and the experiences of Zope 2. The component architecture is the very core of Zope 3 that allows developers to create flexible and powerful web applications. Compatibility with Zope 2 -------------------------- Zope 3 is not upwards compatible with Zope 2. This means you cannot run Zope 2 applications in Zope 3. We continue to work on the transition from Zope 2 to Zope 3 by making Zope 2 use more and more of the Zope 3 infrastructure. This means that new code written in Zope 2 can benefit from Zope 3 technology. Also, with care, code can be written that works in both Zope 3 and Zope 2. This allows a Zope 2 application to slowly evolve towards Zope 3. Unchanged Zope 2 applications are never expected to work in Zope 3, however. Downloads --------- - Zope 3.4 Egg Index: http://download.zope.org/zope3.4 - Zope 3.4 Controlled Packages: http://download.zope.org/zope3.4/controlled-packages.cfg - Zope 3.4 Latest Versions: http://download.zope.org/zope3.4/versions.cfg - The classic Zope 3 source release can be downloaded from: http://zope.org/Products/Zope3 Installation instructions for both Windows and Un*x/Linux are now available in the top level `README.txt` file of the distribution. The binary installer is recommended for Windows. Zope 3.4 requires Python 2.4.4 to run. You must also have zlib installed on your system. Resources --------- - Zope 3 Development Web Site: http://wiki.zope.org/zope3 - Zope 3 Developers Mailing List: http://mail.zope.org/mailman/listinfo/zope-dev Retired: http://mail.zope.org/mailman/listinfo/zope3-dev - Zope 3 Users Mailing List: http://mail.zope.org/mailman/listinfo/zope3-users - Bug tracker at launchpad: https://launchpad.net/zope3 - IRC Channel: #zope3-dev at irc.freenode.net Acknowledgments --------------- Much thanks to everyone who contributed to this release. Since all contributions are now spread over a multitude of packages, listing all contributors is not feasible anymore.
I'll take a risk by stating the obvious. If there will continue to be a release schedule for "Zope 3, the appserver" It would reduce confusion to new users greatly to give the appserver release a name other than Zope. Eg. Current name Proposed name ------------ ------------- "Zope2" -> Zope "Zope3, the libraries" -> Zope libraries "Zope3 the appserver" -> Frobnozz - C Stephan Richter wrote:
January 31, 2008 - The Zope 3 development team announces the Zope 3.4.0c1 release.
This release is the first release candidate for Zope 3.4.0. It was preceeded by an early beta 2 release back in November, 2007.
Zope 3.4 introduces support for binary large objects in the ZODB, and provides a new postprocessing hook for publishing results. Many of the packages also provide small feature improvements that are too numerous to list at this point.
Packages and Eggs -----------------
Since the first Zope 3.4 alpha and beta releases, we have finished the transition to a completely egg-based system. This largely means that most Zope 3 developers do not use the classic Zope 3 tar ball release anymore. However, for your convenience, the Zope 3 developers will provide the classic Zope 3 tar ball releases for at least the 3.4 series and probably for 3.5 as well.
So how are Zope 3 applications built using only eggs?
The Known Good Set (KGS) ~~~~~~~~~~~~~~~~~~~~~~~~
The known good set -- or in short KGS -- is a package index that derives from the official Python Package Index (PyPI) and thus contains all available packages in the Python world. But for a controlled set of packages, only certain versions that are known to work together are available. The list of controlled packages and their versions for Zope 3.4 can be found at the index page [1]_.
The index can be used in several ways -- described here for `buildout`-based projects. The easiest method is to specify the index option in your ``buildout.cfg`` file::
[buildout] index = http://download.zope.org/zope3.4 ...
You can also "nail" the versions by downloading the versions [2]_ and insert them as follows:
[buildout] versions = versions ...
[versions] zope.interface = 3.4.0 ...
``zopeproject`` Project Builder ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Philipp von Weitershausen has developed a package called `zopeproject` to quickly setup the boilerplate for any Zope 3 based project. Ample documentation is provided at the `zopeproject` home page [3]_. `zopeproject` uses Paste or ZDaemon to create a working server. Here are the necessary commands to get a project started::
$ easy_install zopeproject $ zopeproject HelloWorld $ cd HelloWorld $ bin/helloworld-ctl foreground
Demo Packages ~~~~~~~~~~~~~
At this point, there is no demo package demonstrating a simple Zope 3 application setup. (I hope one gets developed before Zope 3.4.0 final.) However, the ``z3c.formdemo`` package can be used as a fairly minimal setup. To get started with it, do the following::
$ svn co svn://svn.zope.org/repos/main/z3c.formdemo/tags/1.5.1 formdemo $ cd formdemo $ python bootstrap.py $ ./bin/buildout -v $ ./bin/demo fg
.. [1] http://download.zope.org/zope3.4/controlled-packages.cfg
.. [2] http://download.zope.org/zope3.4/versions.cfg
.. [3] http://pypi.python.org/pypi/zopeproject
What is Zope 3? ---------------
Zope 3 is a web application server that continues to build on the heritage of Zope. It was rewritten from scratch based on the latest software design patterns and the experiences of Zope 2.
The component architecture is the very core of Zope 3 that allows developers to create flexible and powerful web applications.
Compatibility with Zope 2 --------------------------
Zope 3 is not upwards compatible with Zope 2. This means you cannot run Zope 2 applications in Zope 3.
We continue to work on the transition from Zope 2 to Zope 3 by making Zope 2 use more and more of the Zope 3 infrastructure. This means that new code written in Zope 2 can benefit from Zope 3 technology. Also, with care, code can be written that works in both Zope 3 and Zope 2. This allows a Zope 2 application to slowly evolve towards Zope 3. Unchanged Zope 2 applications are never expected to work in Zope 3, however.
Downloads ---------
- Zope 3.4 Egg Index: http://download.zope.org/zope3.4
- Zope 3.4 Controlled Packages: http://download.zope.org/zope3.4/controlled-packages.cfg
- Zope 3.4 Latest Versions: http://download.zope.org/zope3.4/versions.cfg
- The classic Zope 3 source release can be downloaded from: http://zope.org/Products/Zope3
Installation instructions for both Windows and Un*x/Linux are now available in the top level `README.txt` file of the distribution. The binary installer is recommended for Windows.
Zope 3.4 requires Python 2.4.4 to run. You must also have zlib installed on your system.
Resources ---------
- Zope 3 Development Web Site: http://wiki.zope.org/zope3
- Zope 3 Developers Mailing List: http://mail.zope.org/mailman/listinfo/zope-dev
Retired: http://mail.zope.org/mailman/listinfo/zope3-dev
- Zope 3 Users Mailing List: http://mail.zope.org/mailman/listinfo/zope3-users
- Bug tracker at launchpad: https://launchpad.net/zope3
- IRC Channel: #zope3-dev at irc.freenode.net
Acknowledgments ---------------
Much thanks to everyone who contributed to this release. Since all contributions are now spread over a multitude of packages, listing all contributors is not feasible anymore. _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
On Fri, Feb 1, 2008 at 9:22 AM, Chris McDonough <chrism@plope.com> wrote:
I'll take a risk by stating the obvious.
If there will continue to be a release schedule for "Zope 3, the appserver" It would reduce confusion to new users greatly to give the appserver release a name other than Zope.
Eg.
Current name Proposed name ------------ ------------- "Zope2" -> Zope "Zope3, the libraries" -> Zope libraries "Zope3 the appserver" -> Frobnozz
Isn't this release sort of the last of its kind, though? Kind of a weird time for a name change Or if not, it would seem like there would be a better argument for the new approach having a new name than the old one. --Tom
Tom Hoffman wrote:
On Fri, Feb 1, 2008 at 9:22 AM, Chris McDonough <chrism@plope.com> wrote:
I'll take a risk by stating the obvious.
If there will continue to be a release schedule for "Zope 3, the appserver" It would reduce confusion to new users greatly to give the appserver release a name other than Zope.
Eg.
Current name Proposed name ------------ ------------- "Zope2" -> Zope "Zope3, the libraries" -> Zope libraries "Zope3 the appserver" -> Frobnozz
Isn't this release sort of the last of its kind, though? Kind of a weird time for a name change
I've heard that rumored, but there's nothing indicating that in the release announcement. There are forward looking statements in there: "tarballs... for the last 3.4 series and probably for 3.5 as well." I take this to mean that there's an intention to have a 3.5, 3.6, 3.7 release, etc, but past 3.5, the release won't be packaged as a tarball. If this is the case, even if it's just for 3.5, it would sure help reduce confusion to give this "release of packages" (even if it's just a buildout and the KGS for that release) a name other than "Zope".
Or if not, it would seem like there would be a better argument for the new approach having a new name than the old one.
I'm not sure which is "the new approach" and which is the "old one"? - C
On Feb 1, 2008, at 9:42 AM, Chris McDonough wrote:
Tom Hoffman wrote:
On Fri, Feb 1, 2008 at 9:22 AM, Chris McDonough <chrism@plope.com> wrote:
I'll take a risk by stating the obvious.
If there will continue to be a release schedule for "Zope 3, the appserver" It would reduce confusion to new users greatly to give the appserver release a name other than Zope.
Eg.
Current name Proposed name ------------ ------------- "Zope2" -> Zope "Zope3, the libraries" -> Zope libraries "Zope3 the appserver" -> Frobnozz Isn't this release sort of the last of its kind, though? Kind of a weird time for a name change
I've heard that rumored, but there's nothing indicating that in the release announcement. There are forward looking statements in there: "tarballs... for the last 3.4 series and probably for 3.5 as well." I take this to mean that there's an intention to have a 3.5, 3.6, 3.7 release, etc, but past 3.5, the release won't be packaged as a tarball. If this is the case, even if it's just for 3.5, it would sure help reduce confusion to give this "release of packages" (even if it's just a buildout and the KGS for that release) a name other than "Zope".
Or if not, it would seem like there would be a better argument for the new approach having a new name than the old one.
I'm not sure which is "the new approach" and which is the "old one"?
I'm glad you brought this up. Some observations: - I think the goal of these releases is less to provide an application than to provide a possibly useful collection of some libraries. This is similar to the Python standard library. Some people see significant value in this. I believe that other web frameworks, like TurboGears, also make releases that assemble a bunch of eggs, so people can use their frameworks without having to download eggs from PyPI. - The new approach to making a release would be to create an egg-based release, probably building on zc.sourcerelease. Jim -- Jim Fulton Zope Corporation
On Friday 01 February 2008, Jim Fulton wrote:
- I think the goal of these releases is less to provide an application than to provide a possibly useful collection of some libraries. This is similar to the Python standard library. Some people see significant value in this. I believe that other web frameworks, like TurboGears, also make releases that assemble a bunch of eggs, so people can use their frameworks without having to download eggs from PyPI.
Yes, and I consider this done as soon as I upload a versioned KGS file. Maybe making an announcement as well. The problem right now is that we have not even told people about the eggs or the KGS (many will not pay attention until Zope 3.4.0 final). Nor do we have a transition story. Nor do we have a cohesive "how to use eggs" story and documentation. Many people still customize the Rotterdam skin to build applications in Zope 3!
- The new approach to making a release would be to create an egg-based release, probably building on zc.sourcerelease.
As you know, I am in favor of this approach. But it will take someone to figure out how to do it, write a few scripts and provide a transition to this way of doing it. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
On Fri, Feb 1, 2008 at 9:42 AM, Chris McDonough <chrism@plope.com> wrote:
I've heard that rumored, but there's nothing indicating that in the release announcement. There are forward looking statements in there: "tarballs... for the last 3.4 series and probably for 3.5 as well." I take this to mean that there's an intention to have a 3.5, 3.6, 3.7 release, etc, but past 3.5, the release won't be packaged as a tarball. If this is the case, even if it's just for 3.5, it would sure help reduce confusion to give this "release of packages" (even if it's just a buildout and the KGS for that release) a name other than "Zope".
Or if not, it would seem like there would be a better argument for the new approach having a new name than the old one.
I'm not sure which is "the new approach" and which is the "old one"?
Well, given that this is a very, very late, long planned release always called "Zope 3.4," I'd like to see it come out ASAP without further delay for semantic and philosophical argument. Then we can figure out what to call the next one. --Tom
I would say so also. Since z2, z3 both be released in future as eggs, I I expect the only difference to be in kgs that ensures a working set of packages (whether it is zope3, zope2, or for that matter any other project). Any sort of release in the future should only reflect a state of a working collection of packages. Certainly calling the collection of packages that produces a working zope3 installation a library would be inappropriate in my view. One approach might be calling the releases something zope-kgs-2 and zope-kgs-3 so it is all branded 'zope' - just refer to the *set* of eggs we are taking about. While this is more explicit, it does not sound very nice. kgs looks like kilograms to me any time I look at it :-) It might be nice for the marketing of zope to give each set of eggs a nice name. Just using familiar mozilla names as an illustration, see how nice zope-thunderbird or zope-firefox look. So do away with the kgs in the name and create a brand where zope 2 doesn't look like the lesser version of zope and zope3 isn't a library. They are only sets of the packages we generally refer to as zope :-) Regards, David Tom Hoffman wrote:
Or if not, it would seem like there would be a better argument for the new approach having a new name than the old one.
Hey,. On Feb 1, 2008 4:09 PM, David Pratt <fairwinds@eastlink.ca> wrote: [snip]
It might be nice for the marketing of zope to give each set of eggs a nice name. Just using familiar mozilla names as an illustration, see how nice zope-thunderbird or zope-firefox look. So do away with the kgs in the name and create a brand where zope 2 doesn't look like the lesser version of zope and zope3 isn't a library. They are only sets of the packages we generally refer to as zope :-)
There is this little community project called "Grok" which among other things aims at better marketing of Zope 3 technologies: http://grok.zope.org We've been at it for over a year. Now with all new website! I realize that Grok isn't to the tastes of everybody in this community. They may wish to market non-Grok Zope 3 better. My suggestion is for them to contribute to the Zope website project: http://www.openplans.org/projects/zorg-redux (appears down at the moment, but I think that this is the correct URL) Regards, Martijn
Hi Martijn. I am familiar with grok and the fun and welcoming community you have created. With the perspective I have suggested, releases are only sets with different names giving meaning to each set for developer groups. As a project, grok is currently pinning eggs but can also provide a kgs for the set known as grok. The full story of zope is about the assembly of packages into projects. It need not be only one thing or the other which is the point. It is really up to individual developers to determine their flavor of zope and what it means to their own projects and style of development. My thinking though is that we can create a more cohesive community if the code base were all known as 'zope' and developers are all working from the superset of zope (which is in essence just the code base of packages we all use). Regards, David Martijn Faassen wrote:
Hey,.
On Feb 1, 2008 4:09 PM, David Pratt <fairwinds@eastlink.ca> wrote: [snip]
It might be nice for the marketing of zope to give each set of eggs a nice name. Just using familiar mozilla names as an illustration, see how nice zope-thunderbird or zope-firefox look. So do away with the kgs in the name and create a brand where zope 2 doesn't look like the lesser version of zope and zope3 isn't a library. They are only sets of the packages we generally refer to as zope :-)
There is this little community project called "Grok" which among other things aims at better marketing of Zope 3 technologies:
We've been at it for over a year. Now with all new website!
I realize that Grok isn't to the tastes of everybody in this community. They may wish to market non-Grok Zope 3 better. My suggestion is for them to contribute to the Zope website project:
http://www.openplans.org/projects/zorg-redux
(appears down at the moment, but I think that this is the correct URL)
Regards,
Martijn
On Friday 01 February 2008, Martijn Faassen wrote:
This project does not seem to be public. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Hey, On Feb 1, 2008 6:11 PM, Stephan Richter <srichter@cosmos.phy.tufts.edu> wrote:
On Friday 01 February 2008, Martijn Faassen wrote:
This project does not seem to be public.
I don't know how it's been setup, but if you want to join I'm sure Martin Aspeli can help you. :) Regards, Martijn
On Friday 01 February 2008, Chris McDonough wrote:
If there will continue to be a release schedule for "Zope 3, the appserver" It would reduce confusion to new users greatly to give the appserver release a name other than Zope.
Well, we had to do the classic Zope 3 release at least one more time. Because the official story is still: Download the Zope 3.3 tar ball and start using it. We have to use at least one release to tell people that we are going to change the process and allow them still both methods. I also think that we have no solid story and/or documentation to promote the new approach. My hope is that the story and documentation will develop during the next release cycles. All I am doing is doing something about a pretty pathetic situation. I took the least oath of resistance. And I am particularly tired of name change suggestions! For many reasons. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Stephan Richter wrote:
On Friday 01 February 2008, Chris McDonough wrote:
If there will continue to be a release schedule for "Zope 3, the appserver" It would reduce confusion to new users greatly to give the appserver release a name other than Zope.
Well, we had to do the classic Zope 3 release at least one more time. Because the official story is still: Download the Zope 3.3 tar ball and start using it. We have to use at least one release to tell people that we are going to change the process and allow them still both methods.
Of course.
I also think that we have no solid story and/or documentation to promote the new approach. My hope is that the story and documentation will develop during the next release cycles.
All I am doing is doing something about a pretty pathetic situation. I took the least oath of resistance.
Heh. You're doing yeoman's work.
And I am particularly tired of name change suggestions! For many reasons.
I figured it wouldn't be a popular suggestion. But I do believe it is the right thing. It would have been the right thing from the start, but there is still time to repair things. I typed four more paragraphs full of markety stuff here but deleted them. It's not useful. If no one else thinks it's a good idea, I'm not going to push either. - C
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris McDonough wrote:
Stephan Richter wrote:
On Friday 01 February 2008, Chris McDonough wrote:
If there will continue to be a release schedule for "Zope 3, the appserver" It would reduce confusion to new users greatly to give the appserver release a name other than Zope. Well, we had to do the classic Zope 3 release at least one more time. Because the official story is still: Download the Zope 3.3 tar ball and start using it. We have to use at least one release to tell people that we are going to change the process and allow them still both methods.
Of course.
I also think that we have no solid story and/or documentation to promote the new approach. My hope is that the story and documentation will develop during the next release cycles.
All I am doing is doing something about a pretty pathetic situation. I took the least oath of resistance.
Heh. You're doing yeoman's work.
And I am particularly tired of name change suggestions! For many reasons.
I figured it wouldn't be a popular suggestion. But I do believe it is the right thing. It would have been the right thing from the start, but there is still time to repair things.
I typed four more paragraphs full of markety stuff here but deleted them. It's not useful. If no one else thinks it's a good idea, I'm not going to push either.
I would favor the following for a roadmap going forward: - No more tarball releases, period. Nobody should expect to get another one, or even anything other than a "critical security fix" 3.4.1 tarball. The path for maintenance going forward is going to be to release individual eggs with bugfixes, new features, etc. - Somebody *might* release a meta-egg which would serve the same purpose as the current Zope3 tarball release: it would pull in all the other eggs from the KGS needed to get a "ZMI" up and running. That egg should *not* be called "Zope3": it might be called "z3c.zmi", or some such. There might even be multiple such packages (e.g., one which configures one or more of the example application). - We should fix up our "smoke test" story so that we can do large-scale integration tests of something resembling the current tarball release: this is probably just a buildout, which pulls in all the eggs in the KGS, runs all their unit and functional tests in the integrated environment, and perhaps runs some additional functional / system tests. Note that I am not proposing to release this beast: it exists primarily to enable testing. - Outside applications such as SchoolTool, which currently depend on a released 'zope3", should begin to move their dependencies to the "meta-egg"-based scheme outlined above: in fact, they are probably good candidates for defining such a meta-egg. - Deployments which need non-egg-based packaging will need to figure out how to use the dependency information in the target meta-egg to stitch together their own packages. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHo0xg+gerLs4ltQ4RAmsvAJ9PLQMuz+vQLQRlP07PicWaBlUggwCdFoeB pxcgKOG45yl9DFeokdpPk7c= =Lfhq -----END PGP SIGNATURE-----
On Friday 01 February 2008, Tres Seaver wrote:
I typed four more paragraphs full of markety stuff here but deleted them. It's not useful. If no one else thinks it's a good idea, I'm not going to push either.
I would favor the following for a roadmap going forward:
- No more tarball releases, period. Nobody should expect to get another one, or even anything other than a "critical security fix" 3.4.1 tarball. The path for maintenance going forward is going to be to release individual eggs with bugfixes, new features, etc.
You can only do this, if you have a migration story. We do not have one yet. We do not even have a recommended way of doing eggs-based development. Right now you can use zopeproject or build your own setup. Various recipes provide multiple ways of doing that.
- Somebody *might* release a meta-egg which would serve the same purpose as the current Zope3 tarball release: it would pull in all the other eggs from the KGS needed to get a "ZMI" up and running. That egg should *not* be called "Zope3": it might be called "z3c.zmi", or some such. There might even be multiple such packages (e.g., one which configures one or more of the example application).
This does not fulfill the same use cases as the tar ball release. Look at the story we have for the tar ball. Install it, create an instance, develop using the instance. The meta-egg does not fulfill that story.
- We should fix up our "smoke test" story so that we can do large-scale integration tests of something resembling the current tarball release: this is probably just a buildout, which pulls in all the eggs in the KGS, runs all their unit and functional tests in the integrated environment, and perhaps runs some additional functional / system tests. Note that I am not proposing to release this beast: it exists primarily to enable testing.
I do this already all the time. How else would I know whether the KGS is stable? svn co svn+ssh://svn.zope.org/repos/main/zope.release/branches/3.4 release cd release py24 bootstrap.py ./bin/buildout -N ./bin/generate-buildout cd test py24 ../bootstrap.py ./bin/buildout ./bin/test -vpc1
- Outside applications such as SchoolTool, which currently depend on a released 'zope3", should begin to move their dependencies to the "meta-egg"-based scheme outlined above: in fact, they are probably good candidates for defining such a meta-egg.
Well, ST is already eggified. But they still need a release, so the Ubuntu guys will take the initiative to create the packages. Also, before this can be done, you got to document the process.
- Deployments which need non-egg-based packaging will need to figure out how to use the dependency information in the target meta-egg to stitch together their own packages.
Well, zc.sourcerelease is the recipe we want. But it also needs work to get it going. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris McDonough wrote:
Stephan Richter wrote:
On Friday 01 February 2008, Chris McDonough wrote:
If there will continue to be a release schedule for "Zope 3, the appserver" It would reduce confusion to new users greatly to give the appserver release a name other than Zope. Well, we had to do the classic Zope 3 release at least one more time. Because the official story is still: Download the Zope 3.3 tar ball and start using it. We have to use at least one release to tell people that we are going to change the process and allow them still both methods.
Of course.
I also think that we have no solid story and/or documentation to promote the new approach. My hope is that the story and documentation will develop during the next release cycles.
All I am doing is doing something about a pretty pathetic situation. I took the least oath of resistance.
Heh. You're doing yeoman's work.
And I am particularly tired of name change suggestions! For many reasons.
I figured it wouldn't be a popular suggestion. But I do believe it is the right thing. It would have been the right thing from the start, but there is still time to repair things.
I typed four more paragraphs full of markety stuff here but deleted them. It's not useful. If no one else thinks it's a good idea, I'm not going to push either.
I would favor the following for a roadmap going forward: - No more tarball releases, period. Nobody should expect to get another one, or even anything other than a "critical security fix" 3.4.1 tarball. The path for maintenance going forward is going to be to release individual eggs with bugfixes, new features, etc. - Somebody *might* release a meta-egg which would serve the same purpose as the current Zope3 tarball release: it would pull in all the other eggs from the KGS needed to get a "ZMI" up and running. That egg should *not* be called "Zope3": it might be called "z3c.zmi", or some such. There might even be multiple such packages (e.g., one which configures one or more of the example application). - We should fix up our "smoke test" story so that we can do large-scale integration tests of something resembling the current tarball release: this is probably just a buildout, which pulls in all the eggs in the KGS, runs all their unit and functional tests in the integrated environment, and perhaps runs some additional functional / system tests. Note that I am not proposing to release this beast: it exists primarily to enable testing. - Outside applications such as SchoolTool, which currently depend on a released 'zope3", should begin to move their dependencies to the "meta-egg"-based scheme outlined above: in fact, they are probably good candidates for defining such a meta-egg. - Deployments which need non-egg-based packaging will need to figure out how to use the dependency information in the target meta-egg to stitch together their own packages. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHo0xg+gerLs4ltQ4RAmsvAJ9PLQMuz+vQLQRlP07PicWaBlUggwCdFoeB pxcgKOG45yl9DFeokdpPk7c= =Lfhq -----END PGP SIGNATURE-----
On Fri, Feb 01, 2008 at 11:06:48AM -0500, Chris McDonough wrote:
I typed four more paragraphs full of markety stuff here but deleted them.
*cheers* Marius Gedminas -- The clothes have no emperor. -- C.A.R. Hoare, commenting on ADA.
I'll take that as STFU ;-) Got it. - C Marius Gedminas wrote:
On Fri, Feb 01, 2008 at 11:06:48AM -0500, Chris McDonough wrote:
I typed four more paragraphs full of markety stuff here but deleted them.
*cheers*
Marius Gedminas
------------------------------------------------------------------------
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
On Fri, Feb 01, 2008 at 05:26:14PM -0500, Chris McDonough wrote:
Marius Gedminas wrote:
On Fri, Feb 01, 2008 at 11:06:48AM -0500, Chris McDonough wrote:
I typed four more paragraphs full of markety stuff here but deleted them.
*cheers*
I'll take that as STFU ;-)
It wasn't intended that way. I know from personal experience how hard it is to suppress rants I've written. I was just applauding your self-control. Uhh, not that I'm implying your "markety stuff" was a rant. I'll shut up now. :-) Marius Gedminas -- Place mark here ->[ ]<- if you want a dirty monitor.
Not responding to anyone in particular: I see there are plenty people with opinions. I would love not to do the Zope 3 releases anymore! I am tired of the endless discussions. Think I am frustrated? Absolutely! All the suggestions made here require more work, more manpower. But there is nobody doing the work. In fact, I am not even officially the release manager anymore. Remember, other people took over that job, because they wanted to do a release every 6 months? I said back then: Forget it. Nobody believed me and now it has been almost a year since the 3.3.1 release. The only reason I am doing the releases is to tell the world that we are still out there, improving the framework. And Tom/SchoolTool is the perfect example why this has to be done. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Stephan Richter a écrit :
Not responding to anyone in particular:
I see there are plenty people with opinions. I would love not to do the Zope 3 releases anymore! I am tired of the endless discussions.
Think I am frustrated? Absolutely!
All the suggestions made here require more work, more manpower. But there is nobody doing the work. In fact, I am not even officially the release manager anymore. Remember, other people took over that job, because they wanted to do a release every 6 months? I said back then: Forget it. Nobody believed me and now it has been almost a year since the 3.3.1 release. The only reason I am doing the releases is to tell the world that we are still out there, improving the framework.
I believe the reason of your frustration comes from the fact there are probably not so many people who fully understand the whole release process, the kgs, the buildout, how things are scattered into all these eggs, and all the technology surrounding the transition that zope is going through. I'm not here for a long time and I had to spend hours reading docs and searching every single bit of information in the svn. The transition seems now achieved and the most important thing is to have a dedicated web site with clear information, so that there are new users, and new contributors. When someone goes to the zope.org homepage, there is nothing about zope3, just a single link in the left menu. I've heard that some people have started working on a new web site. Who is doing that job, what is the current status, and what can we do to help? Christophe
And Tom/SchoolTool is the perfect example why this has to be done.
Regards, Stephan
Hey, On Feb 1, 2008 6:04 PM, Christophe Combelles <ccomb@free.fr> wrote: [snip]
The transition seems now achieved and the most important thing is to have a dedicated web site with clear information, so that there are new users, and new contributors. When someone goes to the zope.org homepage, there is nothing about zope3, just a single link in the left menu. I've heard that some people have started working on a new web site. Who is doing that job, what is the current status, and what can we do to help?
I agree that updating the website is important. Martin Aspeli is the person to contact on the zope.org effort. I've cc-ed him here. Earlier in this thread I posted a link to the project as it is on the openplans website. Regards, Martijn
On Feb 2, 2008 12:09 AM, Martijn Faassen <faassen@startifact.com> wrote:
Hey,
On Feb 1, 2008 6:04 PM, Christophe Combelles <ccomb@free.fr> wrote: [snip]
The transition seems now achieved and the most important thing is to have a dedicated web site with clear information, so that there are new users, and new contributors. When someone goes to the zope.org homepage, there is nothing about zope3, just a single link in the left menu. I've heard that some people have started working on a new web site. Who is doing that job, what is the current status, and what can we do to help?
I agree that updating the website is important.
Martin Aspeli is the person to contact on the zope.org effort. I've cc-ed him here. Earlier in this thread I posted a link to the project as it is on the openplans website.
I think the website is one of the huge impediments to joining the Zope community. When you compare zope.org to all the other web framework websites like django, turbogears, and RoR, it is pretty clear why people aren't drawn to Zope 3. Isn't it something of a disgrace that the website for a powerful web application framework is as outdated as zope.org? People don't move to zope for the same reason you wouldn't hire an interior designer who has an ugly house. If things don't really get moving on this front in the near future, it might be a good idea to make zope.org a summer of code project. Would anyone else like to start a new discussion thread on the topic of zope.org? I sure would. Cheers, Paul
Hey, On Feb 1, 2008 8:59 PM, Paul Carduner <paulcarduner@gmail.com> wrote: [snip]
I think the website is one of the huge impediments to joining the Zope community. When you compare zope.org to all the other web framework websites like django, turbogears, and RoR, it is pretty clear why people aren't drawn to Zope 3. Isn't it something of a disgrace that the website for a powerful web application framework is as outdated as zope.org?
Oh, I think everybody agrees. We even have a foundation effort to replace the website (the referenced project). We've had several efforts before; some where I myself was involved, but it's a very difficult thing to move forward. We are moving forward however. Note that meanwhile grok.zope.org *does* present a quite welcoming face to Zope 3 technology - last week we had an all-new website going online. Since we just had to worry about grok for that one, we could move more quickly. We definitely designed it so it wouldn't lose out too badly in the comparison with the websites of other web frameworks.
People don't move to zope for the same reason you wouldn't hire an interior designer who has an ugly house. If things don't really get moving on this front in the near future, it might be a good idea to make zope.org a summer of code project. Would anyone else like to start a new discussion thread on the topic of zope.org? I sure would.
So, as I said above, this is not a new topic. People, including myself, have been pointing this out for years. In public. :) Please do contact Martin Aspeli and join the effort already in progress! Note that we need people who can contribute *content* to the website the most. Those have been the hardest to find in the past. We are beyond technology discussions and the design work is also in good hands. Regards, Martijn
Christophe Combelles wrote:
Stephan Richter a écrit :
Not responding to anyone in particular:
I see there are plenty people with opinions. I would love not to do the Zope 3 releases anymore! I am tired of the endless discussions.
Think I am frustrated? Absolutely!
All the suggestions made here require more work, more manpower. But there is nobody doing the work. In fact, I am not even officially the release manager anymore. Remember, other people took over that job, because they wanted to do a release every 6 months? I said back then: Forget it. Nobody believed me and now it has been almost a year since the 3.3.1 release. The only reason I am doing the releases is to tell the world that we are still out there, improving the framework.
I believe the reason of your frustration comes from the fact there are probably not so many people who fully understand the whole release process, the kgs, the buildout, how things are scattered into all these eggs, and all the technology surrounding the transition that zope is going through. I'm not here for a long time and I had to spend hours reading docs and searching every single bit of information in the svn.
I think you're right on the money. I really have very little idea of how Zope 3 is supposed to be used right now, or what "Zope 3" really is (and no-one fully agrees, as evidenced by other posts in this thread). Having to piece together that information from the mailing list is pretty dire. The website work that the Foundation has commissioned/supported is part of this. It's about mapping out the parts of the Zope universe - Zope 2, CMF, Zope 3 libraries, Grok... People like Philipp and Martijn are drafting the texts and pictures that attempt to clarify all this. When those are public and coherent, we'll see how people react and revise accordingly. That'll help, and will probably be a catalyst for the community to actually get this story straight. Right now it's not. Me? I'm just trying to prod people and manage expectations. Personally, I am fully depenent on the people doing Zope 2 release management and Grok work to make sense of these libraries and package it up in some hopefully-useful way for me to use. I don't think "Zope 3" is a starting point the way Zope 2 is/was - I think it was trying to be that for a while, but that people changed their minds. Now, Grok is the starting point. Maybe Zope 2 w/ Plone form another starting point for a certain audience. Once people know about Zope, they may want to use some of its packages (I used zope.component with Pylons, for example), but that's only if they really want to and already know and love Zope. And yeah - the release management story is a big part of this. As Stephan pointed out, it's completely irresponsible to stop doing (regular!) releases the established way until the new way is clearly defined and documented and a until migration path exists. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin Aspeli wrote:
I think you're right on the money. I really have very little idea of how Zope 3 is supposed to be used right now, or what "Zope 3" really is (and no-one fully agrees, as evidenced by other posts in this thread). Having to piece together that information from the mailing list is pretty dire.
Hi Martin. Today, zope is a superset of functionality. We are all using sets of packages from this superset for our own projects in different ways. It may be hard for someone new to understand that you can have a framework by combining components and the functionality you want from a variety of packages (that may not packaged neatly for you). On the other hand, it is evolution that we are not confined by this also. In fact, it is analogous to python. It provides capability while you provide the imagination and effort to create what you want. I believe that the folks attracted to zope seek something more from it. Zope's has a history of stability, scalability and innovation in python. While I appreciate that django, turbogears, and pylons have their own appeal, zope offers a mature and hardened code base with great strengths. This is not to say zope cannot provide a friendly and welcoming introduction for the python newcomer. I believe Grok provides this while opening the door to the potential of zope in a way that can simplify development. I haven't yet seen the new documentation effort for zope but hope to contribute in some way to help explain what zope is today. I think Tres is accurate and pragmatic in his estimate of the current situation. Since eggs were introduced, strategies to cope with the frustration and growing pains encountered with eggs and setup tools had to be created. Packaging indexes and pinning egg versions were the response to the changes of the last year or so. I understand the desire for continued releases of the monolithic zope. On the other hand I have seen the Grok community respond by pinning its egg versions, Jim Fulton work to facilitate a mirror for distributions, and Stephan assert leadership to create and document a system for kgs to bring sets of eggs under control. The pattern for others working with the older monolithic zope exists in these examples. I believe that sets, indexes, and pinning versions provides the migration path for others. kgs is well documented. The notion of identifying versions in a buildout has been documented too. I believe Tres is spot on. I realize this will mean that projects using the old style releases with need to evolve their development and deployment approaches and do a bit more work to keep their eggs in order. In fact, this is happening all over in the python community at large - not just zope. I was surprised recently to see that even wxPython is working to eggify its releases also. Regards, David
participants (11)
-
Chris McDonough -
Christophe Combelles -
David Pratt -
Jim Fulton -
Marius Gedminas -
Martijn Faassen -
Martin Aspeli -
Paul Carduner -
Stephan Richter -
Tom Hoffman -
Tres Seaver