-----BEGIN PGP SIGNED MESSAGE-----
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.
>> 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
>> 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
> 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.
> not useful. If no one else thinks it's a good idea, I'm not going to push
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 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
-----END PGP SIGNATURE-----
Zope3-users mailing list