-----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 [EMAIL PROTECTED] 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----- _______________________________________________ Zope3-users mailing list Zope3firstname.lastname@example.org http://mail.zope.org/mailman/listinfo/zope3-users