-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
On Sep 22, 2006, at 11:47 AM, Martijn Faassen wrote:
Hi there,
I am about to do a new egg release of zc.catalog and will be putting
out other eggs as well (to the cheeseshop as we now have our own
category there).
I notice in the SVN that there have been quite a few changes to
zc.catalog. We do not have any CHANGES.txt or such, so it's very hard
for me to determine what in fact changed without digging through SVN
commit messages and such.
So, I propose we start maintaining CHANGES.txt in packages, and mark
changes there when we make them.
I'd rather see this in projects, not packages. So this would be in the
root of an SVN project alongside of setup.py.
Maybe this is what you meant.
The format I propose is in restructured text, like so:
==
zc.catalog changes
==
0.2 (2006-11-22)
Features added
--
* zc.catalog can now do even more wonderful things.
Bugs fixed
--
* fixed a bug where zc.catalog wasn't doing the right thing.
What do you think?
See what I've been doing for zc.buildout:
http://svn.zope.org/zc.buildout/trunk/CHANGES.txt?view=auto
Some things to note:
I knit all of the .txt files, including documentation-oriented doctest
files together in the distutils long description. This causes the pypi
page to be pretty informative:
http://www.python.org/pypi/zc.buildout
The knitting happens in setup.py,
http://svn.zope.org/zc.buildout/trunk/setup.py?rev=70198view=auto
While this is still pretty experimental, I'm pretty happy with it.
To make this work requires coordinating headings across all of the text
files. which lead to my use of *s in the root text files.
Also, for individual packages, I think we can be a little more
lightweight. For example, I think we can avoid separating features and
bugs.
- -1. I *like* the split, as it forces the maintainer to think harder
about how to present the release to the world (ultra-stable vs.
current vs. in development)
I also think it's nice to provide some information about status and plans.
I find putting dates on releases to be a bother. If it's a bother for
me, it's probably a bother for others. Is it really worth it?
Absolutely. Correlating what release happended when by grubbing through
the logs is a chore, but better the releasing maintainer does it (once),
and then keeps it aligned, than have everybody who might need to use the
package have to do so.
I've done a bad job of tagging releases, I need to get better about that.
Finally, I'm experimenting with using launchpad for bugs:
https://launchpad.net/products/zc.buildout/+bugs
and feature requests:
https://features.launchpad.net/products/zc.buildout/
So far this is working OK. I haven't really stressed it. Launchpad makes
this very easy to set up and I don't think they are allergic to having
us create lots of projects.
If we're going to change horses, I'd rather go to something which can
correlate checkins with issues, via some kind of convention about
spelling the issue ID in the commit message (Trac, cvstrac, etc. do
this). I don't know whether launchpad can be persuaded to do this
(maybe via subscription to a checkins list?)
Tres.
- --
===
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFFZu2+gerLs4ltQ4RAkWYAKCLI/PHLTV5q2NshdXbRu+dxFnctQCffhmU
XS4CC2Uu6hvKajR1JVYDZHI=
=FzOf
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
