Provided by: libdist-zilla-plugin-changelogfromgit-perl_0.016-1_all bug

NAME

       Dist::Zilla::Plugin::ChangelogFromGit - Write a Changes file from a project's git log.

VERSION

       version 0.016

SYNOPSIS

       Here's an example dist.ini section showing all the current options and their default
       values.

               [ChangelogFromGit]
               max_age     = 365
               tag_regexp  = ^v(\d+\.\d+)$
               file_name   = CHANGES
               wrap_column = 74
               debug       = 0

       Variables don't need to be set to their default values.  This is equivalent to the
       configuration above.

               [ChangelogFromGit]

DESCRIPTION

       This Dist::Zilla plugin turns a project's git commit log into a change log file.  It's
       better than simply running `git log > CHANGES` in at least two ways.  First, it
       understands release tags, and it uses them to group changes by release.  Second, it
       reformats the changes to make them easier to read.  And third, subclasses can change some
       or all of the reformatting to make change logs even easier to read.

       See this project's CHANGES file for sample output.  Yes, this project uses itself to
       generate its own change log.  Why not?

CONFIGURATION / PUBLIC ATTRIBUTES

       As seen in the "SYNOPSIS", this plugin has a number of public attributes that may be set
       using dist.ini configuration variables.

   max_age = INTEGER
       The "max_age" configuration variable limits the age of releases to be included in the
       change log.  The default is to include releases going back about a year.  To include about
       two years, one would double the default value:

               [ChangelogFromGit]
               max_age = 730

       "max_age" is intended to limit the size of change logs for large, long-term projects that
       don't want to include the entire, huge commit history in every release.

   tag_regexp = REGULAR_EXPRESSION
       "tag_regexp" sets the regular expression that detects which tags mark releases.  It also
       extracts the version numbers from these tags using a regular expression back reference or
       capture.  For example, a project's release tags might match 'release-1.000',
       'release-1.001', etc.  This "tag_regexp" will find them and extract their versions.

               [ChangelogFromGit]
               tag_regexp = ^release-(\d+.*)$

       There is no single standard format for release tags.  "tag_regexp" defaults to the
       author's convention.  It will most likely need to be changed.

   file_name = STRING
       "file_name" sets the name of the change log that will be written.  It defaults to
       "CHANGES", but some people may prefer "Changes", "Changelog", or something else.

               [ChangelogFromGit]
               file_name = Changes

   wrap_column = INTEGER
       Different contributors tend to use different commit message formats, which can be
       disconcerting to the typographically aware release engineer.  "wrap_column" sets the line
       length to which all commit messages will be re-wrapped.  It's 74 columns by default.  If
       this is too short:

               [ChangelogFromGit]
               wrap_column = 78

   debug = BOOLEAN
       Developers are people, too.  The "debug" option enables some noisy runtime tracing on
       STDERR.

               [ChangelogFromGit]
               debug = 1

   exclude_message = REGULAR_EXPRESSION
       "exclude_message" sets a regular expression which discards matching commit messages.  This
       provides a way to exclude commit messages such as 'forgot to include file X' or 'typo'.
       The regular expression is case sensitive.

               [ChangelogFromGit]
               exclude_message = ^(forgot|typo)

       "include_message" can be used to do the opposite: exclude all changes except ones that
       match a regular expression.  Using both at once is liable to generate empty change logs.

   include_message = REGULAR_EXPRESSION
       "include_message" does the opposite of "exclude_message": it sets a regular expression
       which commit messages must match in order to be included in the Changes file.  This means
       that when making a commit with a relevant message, you must include text that matches the
       regular expression pattern to have it included in the Changes file.  All other commit
       messages are ignored.

       The regular expression is case sensitive.

               [ChangelogFromGit]
               include_message = ^Major

       Using both "include_message" and "exclude_message" at the same time will most likely
       result in empty change logs.

HOW IT WORKS

       Dist::Zilla::ChangelogFromGit collects the tags matching "tag_regexp" that are not older
       than "max_age" days old.  These are used to identify and time stamp releases.  Each
       release is encapsulated into a Software::Release object.

       Git::Repository::Log::Iterator is used to collect the changes prior to each release but
       after the previous release.  Change log entries are added to their respective
       Software::Release objects.

       "$self->render_changelog()" is called after all the relevant releases and changes are
       known.  It must return the rendered change log as a string.  That string will be used as
       the content for a Dist::Zilla::File::InMemory object representing the new change log.

SUBCLASSING FOR NEW FORMATS

       Dist::Zilla::ChangelogFromGit implement about a dozen methods to render the various parts
       of a change log.  Subclasses may override or augment any or all of these methods to alter
       the way change logs are rendered.

       All methods beginning with "render" return strings that will be incorporated into the
       change log.  Methods that will not contribute to the change log must return empty strings.

   Rendering Entire Change Logs
       Methods beginning with "render_changelog" receive no parameters other than $self.
       Everything they need to know about the change log is included in the object's attributes:
       "wrap_column", "releases", "skipped_release_count", "earliest_date".

       render_changelog

       render_changelog() returns the text of the entire change log.  By default, the change log
       is built from a header, zero or more releases, and a footer.

               sub render_changelog {
                       my $self = shift();
                       return(
                               $self->render_changelog_header() .
                               $self->render_changelog_releases() .
                               $self->render_changelog_footer()
                       );
               }

       render_changelog_header

       render_changelog_header() renders some text that introduces the reader to the change log.

               sub render_changelog_header {
                       my $self = shift();
                       my $header = (
                               "Changes from " . $self->format_datetime($self->earliest_date()) .
                               " to present."
                       );
                       return $self->surround_line("=", $header) . "\n";
               }

       render_changelog_releases

       render_changelog_releases() iterates through each release, calling upon $self to render
       them one at a time.

               sub render_changelog_releases {
                       my $self = shift();

                       my $changelog = '';

                       RELEASE: foreach my $release (reverse $self->all_releases()) {
                               next RELEASE if $release->has_no_changes();
                               $changelog .= $self->render_release($release);
                       }

                       return $changelog;
               }

       render_changelog_footer

       render_changelog_footer() tells the reader that the change log is over.  Normally the end
       of the file is sufficient warning, but a truncated change log is friendlier when the
       reader knows what they're missing.

               sub render_changelog_footer {
                       my $self = shift();

                       my $skipped_count = $self->skipped_release_count();

                       my $changelog_footer;

                       if ($skipped_count) {
                               my $releases = "release" . ($skipped_count == 1 ? "" : "s");
                               $changelog_footer = (
                                       "Plus $skipped_count $releases after " .
                                       $self->format_datetime($self->earliest_date()) . '.'
                               );
                       }
                       else {
                               $changelog_footer = "End of releases.";
                       }

                       return $self->surround_line("=", $changelog_footer);
               }

   Rendering Individual Releases
       Methods beginning with "render_release" receive $self plus one additional parameter: a
       Software::Release object encapsulating the release and its changes.  See Software::Release
       to learn the information that object encapsulates.

       render_release

       render_release() is called upon to render a single release.  In the change log, a release
       consists of a header, one or more changes, and a footer.

               sub render_release {
                       my ($self, $release) = @_;
                       return(
                               $self->render_release_header($release) .
                               $self->render_release_changes($release) .
                               $self->render_release_footer($release)
                       );
               }

       render_release_header

       render_release_header() introduces a release.

               sub render_release_header {
                       my ($self, $release) = @_;

                       my $version = $release->version();
                       $version = $self->zilla()->version() if $version eq 'HEAD';

                       my $release_header = (
                               $self->format_release_tag($release->version()) . ' at ' .
                               $self->format_datetime($release->date())
                       );

                       return $self->surround_line("-", $release_header) . "\n";
               }

       render_release_changes

       render_release_changes() iterates through the changes associated with each
       Software::Release object.  It calls upon render_change() to render each change.

               sub render_release_changes {
                       my ($self, $release) = @_;

                       my $changelog = '';

                       foreach my $change (@{ $release->changes() }) {
                               $changelog .= $self->render_change($release, $change);
                       }

                       return $changelog;
               }

       render_release_footer

       render_release_footer() may be used to divide releases.  It's not used      by default,
       but it's implemented for completeness.

               sub render_release_footer {
                       my ($self, $release) = @_;
                       return '';
               }

   Rendering Individual Changes
       Methods beginning with "render_change" receive two parameters in addition to $self: a
       Software::Release object encapsulating the release containing this change, and a
       Software::Release::Change object encapsulating the change itself.

       render_change

       render_change() renders a single change, which is the catenation of a change header,
       change message, and footer.

               sub render_change {
                       my ($self, $release, $change) = @_;
                       return(
                               $self->render_change_header($release, $change) .
                               $self->render_change_message($release, $change) .
                               $self->render_change_footer($release, $change)
                       );
               }

       render_change_header

       render_change_header() generally renders identifying information about each change.  This
       method's responsibility is to produce useful information in a pleasant format.

               sub render_change_header {
                       my ($self, $release, $change) = @_;

                       use Text::Wrap qw(fill);

                       local $Text::Wrap::huge    = 'wrap';
                       local $Text::Wrap::columns = $self->wrap_column();

                       my @indent = ("  ", "  ");

                       return(
                               fill(
                                       "  ", "  ",
                                       'Change: ' . $change->change_id
                               ) .
                               "\n" .
                               fill(
                                       "  ", "  ",
                                       'Author: ' . $change->author_name.' <'.$change->author_email.'>'
                               ) .
                               "\n" .
                               fill(
                                       "  ", "  ",
                                       'Date  : ' . $self->format_datetime($change->date())
                               ) .
                               "\n\n"
                       );
               }

       render_change_message

       render_change_message() renders the commit message for the change log.

               sub render_change_message {
                       my ($self, $release, $change) = @_;

                       use Text::Wrap qw(fill);

                       return '' if $change->description() =~ /^\s/;

                       local $Text::Wrap::huge = 'wrap';
                       local $Text::Wrap::columns = $self->wrap_column();

                       return fill("    ", "    ", $change->description) . "\n";
               }

       render_change_footer

       render_change_footer() returns summary and/or divider text for the change.

               sub render_change_footer {
                       my ($self, $release, $change) = @_;
                       return "\n";
               }

   Formatting Data
       Dist::Zilla::Plugin::ChangelogFromGit includes a few methods to consistently format
       certain data types.

       format_datetime

       format_datetime() converts the DateTime objects used internally into friendly, human
       readable dates and times for the change log.

               sub format_datetime {
                       my ($self, $datetime) = @_;
                       return $datetime->strftime("%F %T %z");
               }

       format_release_tag

       format_release_tag() turns potentially cryptic release tags into friendly version numbers
       for the change log.  By default, it also replaces the 'HEAD' version with the current
       version being released.  This accommodates release managers who prefer to tag their
       distributions after releasing them.

               sub format_release_tag {
                       my ($self, $release_tag) = @_;

                       return 'version ' . $self->zilla()->version() if $release_tag eq 'HEAD';

                       my $tag_regexp = $self->tag_regexp();
                       $release_tag =~ s/$tag_regexp/version $1/;
                       return $release_tag;
               }

       surround_line

       surround_line() will surround a line of output with lines of dashes or other characters.
       It's used to help heading stand out.  This method takes two strings: a character (or
       string) that will repeat to fill surrounding lines, and the line to surround.  It returns
       a three-line string: the original line preceded and followed by surrounding lines.

               sub surround_line {
                       my ($self, $character, $string) = @_;

                       my $surrounder = substr(
                               ($character x (length($string) / length($character) + 1)),
                               0,
                               length($string)
                       );

                       return "$surrounder\n$string\n$surrounder\n";
               }

INTERNAL ATTRIBUTES

       Dist::Zilla::Plugin::ChangelogFromGit accumulates useful information into a few internal
       attributes.  These aren't intended to be configured by dist.ini, but they are important
       for rendering change logs.

   earliest_date
       earliest_date() contains a DateTime object that represents the date and time of the
       earliest release to include.  It's initialized as midnight for the date max_age() days
       ago.

   releases
       releases() contains an array reference of Software::Release objects that will be included
       in the change log.

       all_releases

       all_releases() returns a list of the Software::Release objects that should be included in
       the change log.  It's a friendly equivalent of "@{$self->releases()}".

       get_release

       get_release() returns a single release by index.  The first release in the change log may
       be retrieved as "$self->get_release(0)".

       releae_count

       release_count() returns the number of Software::Release objects in the "releases"
       attribute.

       sort_releases

       sort_releases() sorts the Software::Release objects in the releases() using some
       comparator.  For example, to sort releases in time order:

               $self->sort_releases(
                       sub {
                               DateTime->compare( $_[0]->date(), $_[1]->date() )
                       }
               );

   skipped_release_count
       skipped_release_count() contains the number of releases truncated by max_age().  The
       default render_changelog_footer() uses it to display the number of changes that have been
       omitted from the log.

Subversion and CVS

       This plugin is almost entirely a copy-and-paste port of a command-line tool I wrote a
       while ago.  I also have tools to generate similar change logs for CVS and Subversion
       projects.  I'm happy to contribute that code to people interested in creating Dist::Zilla
       plugins for other version control systems.

       We should also consider abstracting the formatting code out to a role so that it can be
       shared among different plugins.

BUGS

       The documentation includes copies of the renderer methods.  This increases technical debt,
       since changes to those methods must also be copied into the documentation.  Rocco needs to
       finish Pod::Plexus and use it here to simplify maintenance of the documentation.

       Collecting all releases and changes before rendering the change log may be considered
       harmful for extremely large projects.  If someone thinks they can generate change logs
       incrementally, their assistance would be appreciated.

AUTHORS

       Rocco Caputo <rcaputo@cpan.org> - Initial release, and ongoing management and maintenance.

       Cory G. Watson <gphat@cpan.org> - Made formatting extensible and overridable.

COPYRIGHT AND LICENSE

       This software is copyright (c) 2010-2013 by Rocco Caputo.

       This is free software; you may redistribute it and/or modify it under the same terms as
       the Perl 5 programming language itself.