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
svn co svn+ssh://svn.zope.org/repos/main/zope.release/branches/3.4 release
> - 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
Web Software Design, Development and Training
Google me. "Zope Stephan Richter"
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -