-----BEGIN PGP SIGNED MESSAGE-----
Philipp von Weitershausen wrote:
> We have 100+ packages that make up what used to be distributed as
> "Zope3". We have numerous more packages in svn.zope.org. Most of them
> are developed, released and distributed individually. We like to think
> this is a good thing (I certainly do). But currently we have a bit of a
> chaos . It's not bad, but I fear without some guidance, it'll get worse.
> Christian Theune recently wrote a document  in which he outlined how
> we should get to a development process and what topics it should touch.
> This document is very hands-on and describes actions that should be
> taken to reach these goals. I've taken the liberty to jump ahead and
> write down some current practices:
Thanks for drafting this document. A couple of comments (mostly niggles).
- At then end of the last summary bullet under "Repository layout",
you say, "Release tags shouldn't be committed to." I would say
that is true *after* the release is announced. Sometimes it may
be more convenient to modify the tagged code during the process of
making the release (see below).
- The changelog should include dates for each release, formatted
consistently (ISO short form is likely best, as it is unambiguous).
- Under "Releasing Software", you specify what is to me a controversial
rule: "Increase the version number (in ``setup.py`` and elsewhere)
on the trunk or the release branch to the *next* release." While I
realize that many projects are doing this, I don't like it: I prefer
that the trunk changelog contain an "unreleased" section for features
/ changes not tracked on the current release branch.
In particular, I don't want to make it easy for somebody with a trunk
or branch checkout to create a pseudo-release egg. In this case,
"speed kills", because sloppy release making punishes everybody
I would therefore advocate keeping the 'version' tag on the trunk to
something containing 'trunk' or 'unreleased'. Release branches
should contain 'branch' in their version, except immediately before
copying to a release tag. As an alternative (see above), copy the
release tag and then change the version there.
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-dev mailing list