[Zope-dev] Re: Zope 3.4.0 candidate 1 Released
-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 Designhttp://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- ___ 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 )
[Zope-dev] Re: Zope 3.4.0 candidate 1 Released
-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 Designhttp://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- ___ 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 )
Re: [Zope-dev] Re: Zope 3.4.0 candidate 1 Released
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 ___ 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 )
