-----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-----