On 11 Apr 2007, at 08:21 , Christian Theune wrote:
* Will we create the tarball with zpkg? What about the Windows release?


Yes, we will stay with creating the release zpkg-based. We tried to come up with an egg/buildout-based approach to assemble something that looks
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.

Ack.

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 maintaining the release cycles of the individual packages). Tagging basically also
     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 CheeseShop
     and/or download.zope.org?

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 to the
     CheeseShop, to download.zope.org or to both?

There's been a small amount of discussion at PyCon and maybe in IRC that
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 that
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, just in
a set of eggs instead of a tarball"

Bad points:

- we probably will use this approach to procrastinate on getting the
dependencies right, meaning, if we get the dependencies (and the version
dependencies) right, then we shouldn't need this release directory

Indeed.


_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to