Perhaps the following can be used?
https://github.com/vaab/gitchangelog#gitchangelog
That does impose a commit message format, but then any kind of release
notes generated from a commit log will require some sort of standard to
be maintained (otherwise it's going to be tough to auto-generate
anything useful).
Maybe `gitchangelog` has to much structure required, but at least its an
example that can be looked at (vs. recreating our own).
Doug Hellmann wrote:
Excerpts from Robert Collins's message of 2015-08-04 06:43:48 +1200:
On 4 August 2015 at 02:46, Alexis Lee<alex...@hp.com> wrote:
Thierry Carrez said on Mon, Aug 03, 2015 at 02:57:39PM +0200:
1. we can maintain a Changelog document directly in the source code.
Rather than being straightly backported from master, commits with
significant changes would be amended to additionally modify that document.
Wouldn't this cause a lot of rebasing as everyone tries to get in at the
top?
2. we come up with a keyword in commit messages ("ReleaseNotes:" ?) and
amend only the commit message of significant backports. Automation picks
up those and autogenerates a Release Notes document that gets included
in generated source code tarballs.
Whichever solution we pick - should we also adopt it on master? Naively
it sounds useful to be able to generate release notes for master too.
And this avoids inconsistency between master and stable beyond that
required to rebase.
Explanations of the many ways I'm wrong are always appreciated.
I think you're right on.
Something with the same process as ChangeLog generation today - read
from git, process, output document - will be much less fragile for
merges.
We could use the same convention for highlighting changes in libraries,
and pull the messages out for the release announcements.
How detailed do we want release notes to be? For example, do we need to
worry about supporting multiple paragraphs or ASCII art or anything like
that?
Doug
-Rob
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
