diff options
| author | W. Trevor King <wking@drexel.edu> | 2009-07-21 16:33:28 -0400 |
|---|---|---|
| committer | W. Trevor King <wking@drexel.edu> | 2009-07-21 16:33:28 -0400 |
| commit | 885b04b50ad3bbde81ec2eccfbfb2e516d0d3a80 (patch) | |
| tree | 794458babd1aa824b3e343291f6c5f2d7704f27f /.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body | |
| parent | 19fc927cf959005a71813ca702fc6c1aa28d3a92 (diff) | |
| parent | 86d74730ded314d960e0465f2eb50e5fb66c4767 (diff) | |
| download | bugseverywhere-885b04b50ad3bbde81ec2eccfbfb2e516d0d3a80.tar.gz | |
Merged assorted changes from be.wtk-rr for BugDir.extra_strings.
Other highlights:
* be show --no-comments
* Improved *.sync_with_disk.
* Improved be-mbox-to-xml.
Diffstat (limited to '.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body')
| -rw-r--r-- | .be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body | 30 |
1 files changed, 30 insertions, 0 deletions
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body new file mode 100644 index 0000000..063afcb --- /dev/null +++ b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/aad59898-8949-44fb-ad0b-2acea6eb2ef8/body @@ -0,0 +1,30 @@ +Hi, + + > That's not a changelog, that's a commit log of every source-level + > commit made. Far too much detail for a changelog of + > *user-visible* changes associated with a release. + +I think I agree with both of you. :) It seems like it's both true that +there's no point in keeping a GNU-style ChangeLog these days, and that +if we make a release we should write an announce mail that directly +mentions new user-visible changes as well as attaching the commit log. +That smaller list of highly user-visible changes could live in NEWS, +or in the announce mail, or both. + + > I agree that's a problem. I think the solution is to start making + > releases, with specific version strings, as source tarballs. + +I'm happy to do this if people think it would be useful, and I don't +yet have a strong opinion on whether the releases should come with +version numbers or timestamps. + +Thanks, + +- Chris. +-- +Chris Ball <cjb@laptop.org> + +_______________________________________________ +Be-devel mailing list +Be-devel@bugseverywhere.org +http://void.printf.net/cgi-bin/mailman/listinfo/be-devel |