Christian Theune wrote:
All eggs of a particular release will be available from : .  Here is some future

  3.4.0 - distribution/zope3/3.4.0
  3.4.1 - distribution/zope3/3.4.1
  3.5.0 - distribution/zope3/3.5.0

For 3.4.0 all individual packages will be having a unique version
number (3.4.0), but this won't be the case for 3.5.0, in Zope 3.5.0
zope.interface may be still in 3.4.0 version.

In PyPI we will put all latest stable releases of individual packages,
so a package in PyPI may be a newer version compared to the latest
Zope 3 release.  Then, to install a particular Zope 3 release, user
should always use as eggs location
(--find-links option in easy_install or zc.buildout).

I think we can have a meta-package for "the Zope application" that
defines a dependency for all packages, some of those might still be
3.4.0 whilst others might be 3.5.1 etc. I don't think we really need the
download areas to gather the eggs.

We *should* make 'zpkg' based releases, until 3.6 release.

Right. Maybe even longer, I don't know.


We *should* be making releases that you install using "configure; make; make install", but they don't necessarily have to use zpkg. I would prefer if they'd install eggs.

We *really* have to start
spreading the word on how to develop a Zope application with buildout if
we want to retire our normal releases.


Documenting buildout is one thing, eggifying Zope another. I personally don't think we should be tying Zope 3 developers to buildout. It's a nice tool for some things, for others it's not.

What we *should* do is teach people how to use an eggified Zope.

We also have to think about the PR issues we're gonna face IMHO. We
might decide to not do anything for PR, but we should have looked at the
consequences and know what we're heading for.

Not sure what that means.

-- -- Professional Zope documentation and training
Zope3-dev mailing list

Reply via email to