On 11 Apr 2007, at 08:21 , Christian Theune wrote:
* Will we create the tarball with zpkg? What about the Windows
Yes, we will stay with creating the release zpkg-based. We tried to
up with an egg/buildout-based approach to assemble something that
like an old-style release but this didn't work out for the 3.4 release
because of time constraints.
Ok. That's certainly ok. Since we have the eggs, nobody will be
forced to use the tarball...
This raises the following questions:
- I think we need to tag all individual packages as well.
And by tagging, I obviously mean that the external of the tag needs
to point to the 3.4.x tag in Zope 3.x.
- If so, WHO tags them? (I would hope that we can determine
maintainers for each zope.* package who will start
release cycles of the individual packages). Tagging basically
means updating setup.py.
Can we automate that?
Perhaps for the first round. The question is whether it'll be
necessary to release all packages all the time in the future. I
expect certain packages to change very little while others might or
might not change rapidly, depending on whether they're improved or not.
Also, we should start thinking about maintaining individual
CHANGES.txt (with the general Zope 3's CHANGES.txt being a [perhaps
automated] compilation of the individual CHANGES.txt).
Furthermore, we've split up zope.app into different eggs, but we
haven't split up the translations.
Perhaps we don't need to do these things for 3.4, but they all feel
pretty release-y to me.
- Who physically creates the eggs and uploads them to the
The one who runs the automated script? ;)
-0. I would hope that people from the community would adopt certain
zope.* packages and maintain their release cycles. They could have
largely independent release cycles of Zope that only need to be
synchronized every 6 to 9 months when we do a general Zope 3 release
(which might not even need to happen in the future).
For now we could do the automated script.
- That last point raises another question: Do we upload things
CheeseShop, to download.zope.org or to both?
There's been a small amount of discussion at PyCon and maybe in IRC
points out that we could have a directory on download.zope.org that
contains all eggs for one release. You can point your find-links to
and get exactly the eggs of the 3.4 release (branch).
Good points about this approach:
- central visible place for each release
- the goal to create a set of eggs that where tested together
- the feeling for people to know "ok, this is what zope 3.4 is,
a set of eggs instead of a tarball"
- we probably will use this approach to procrastinate on getting the
dependencies right, meaning, if we get the dependencies (and the
dependencies) right, then we shouldn't need this release directory
Zope3-dev mailing list