-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 [2]. It's not bad, but I fear without some guidance, it'll get worse. > > Christian Theune recently wrote a document [1] 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: > > http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt
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 downstream. 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. - -- =================================================================== 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 iD8DBQFG0FPk+gerLs4ltQ4RAgn7AJ9BG0hcMn+cBkx6+1qW4bIeurlJQgCfa1l7 lVrgMfItaGX44N1fUBKBZwQ= =xvIa -----END PGP SIGNATURE----- _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com