> $ git log --pretty=format:"%h - %an : %s" v0.1.19..v0.1.20
What about
$ git shortlog HEAD...`git describe`
which gives you the commits and number of commits by author?

IMHO these could be helpful when creating such release notes page [1] for
> future releases (but on the other hand to keep them in reasonable count).
Definitely want to keep them at reasonable count, but committers would need to make sure that the tags are correct for PRs/Issues (depending on how the project thinks how strict committers should be).


On Fri, Jan 16, 2015 at 2:26 AM, Jan Lieskovsky <jlieskov@redhat.com> wrote:

Thanks, Shawn.

----- Original Message -----
> From: "Shawn Wells" <shawn@redhat.com>
> To: scap-security-guide@lists.fedorahosted.org
> Sent: Thursday, January 15, 2015 10:53:53 PM
> Subject: Re: Can you recommend a way how to share more detailed release       changelog information via GitHub web UI?
>
>
> On 1/15/15 8:54 AM, Jan Lieskovsky wrote:
>
>
>
> Hello folks,
>
>   in effort to create new SCAP Security Guide v0.1.20 release and mainly
> trying to provide more detailed Changelog information, that would be
> reachable online (yet before the actual tarball has been downloaded &
> expanded) has been investigating GitHub web UI possibilities for this
> purpose.
>
> One approach how this could be implemented is to provide the Changelog
> information in the particular milestone's description. But the problem
> seems to be there isn't a direct link provided how such milestone's
> description could be referenced later.
>
> Example content is visible at:
> 1) https://github.com/OpenSCAP/scap-security-guide/milestones to get the list
> of milestones
>
> 2) then click the "(more)" pseudo link below
>    "Version 0.1.20: USGCB profile remediation and kickstart support"
>    milestone to see the actual description.
>
> From what I have searched looks this "(more)" pseudo link is handled
> by JavaScript (thus at the side of the client's browser) and it's not
> possible to use it for referential purposes.
>
> The vision behind future SCAP Security Guide updates is to provide
> also more detailed Changelog information for each release, basically
> split into three sections:
>
>   * New Features:
>
>   This not so much detailed section would be dedicated to briefly list
>   main new features expected to be provided in this release (like support
>   of new products etc.)
>
>   * Enhancements:
>
>   Here list of enhancements would be detailed (IOW enhancements for existing
>   products like new remediations or new OVAL checks).
>
>   * Bug fixes:
>
>   Here list of bug fixes would be described (which build failures / OVAL
>   checks /
>   remediations have been corrected in this release).
>
> Given (after the short review so far) the GitHub's milestone's description
> doesn't
> seem to be providing functionality for this kind of "web Changelog" was
> thinking
> of creating new GitHub SCAP Security Guide wiki page for each of the new
> releases
> and detailing that information there.
>
> But prior doing that wanted to check experiences of other people / other
> ideas /
> suggestions, how this could be implemented.
>
> Comments / recommendations / experience / proposals welcome.
>
> Between v0.1.19 and v0.1.20:
> https://github.com/OpenSCAP/scap-security-guide/compare/v0.1.19...v0.1.20
>
> v0.1.20 through current/MASTER:
> https://github.com/OpenSCAP/scap-security-guide/compare/v0.1.20...master
> (note: since nothing was committed since this morning, nothing will be here)

(Since I am still exploring the possibilities of GitHub's project web UI),
these are handy to be aware of.

Maybe better to describe the motivation behind these documents - I am searching
for a way how to create text documents describing the release (to prepare
release notes & purpose clarification / mission statement for the new release).

These additional data should provide answers to questions like:
* what's the difference among these two releases. Why should I install the most
recent one?

* creating more detailed changelog helps return to the release version after
some time to see what was the progress, what were the features etc. While
git commits are natural to developers, it might not be that straightforward
for end users - they are mainly searching / interested if some concrete feature
has been implemented / some concrete bug has been fixed, not interested that
much in all of the related necessary patches, that were required to be applied
with that change together for proper work.

* for the future features document - where are they tracked, is there a list,
can I contribute to the list, can I contribute by voting if something will be
fixed in prioritized way?

Having had look at the GitHub milestone's & wiki functionality, for now
decided to:
* milestones
  * for past releases to track just release highlits and provide full feature changelog on
    the dedicated wiki page (for example have a look at new content of:
    "Version 0.1.20: USGCB profile remediation and kickstart support"
    under "(more)" link

   The full release changelog is then available here:
   [1] https://github.com/OpenSCAP/scap-security-guide/wiki/scap-security-guide-0.1.20-Release-Notes

  * for future releases to track summary of new features, maybe feature tags
   and link to proposed feature page (for example have a look at new content of:
   "Version 0.1.21: RHEL-6 USGCB stabilization towards Tier IV" (again see the
   "(more)" link)

   The full proposed features page is then available here:
   [2] https://github.com/OpenSCAP/scap-security-guide/wiki/SCAP-Security-Guide-0.1.21-Proposed-Features

In the moment of new release the release engineer would freeze the new features page
& create a release notes document for that release.

Hopefully this will be perceived as the proper step to increase
the transparency across past & future SCAP Security Guide releases
(end users able to quickly to find consumable diff what's got changed for
past releases & also able to participate on future features).

>
> Or from the CLI, you can do something like:
>
>
> $ git log --pretty=format:"%h - %an : %s" v0.1.19..v0.1.20
> 1bb6240 - iankko : Merge pull request #382 from iankko/version_0.1.20
> 3de0fae - Jan Lieskovsky : Make new 0.1.20 release
> 2de0a05 - Martin Preisler : Merge pull request #381 from
> iankko/pam_faillock_deny_fix_oval
> 45792dd - Jan Lieskovsky : [shared] accounts_passwords_pam_faillock_deny OVAL
> check:
> a806cad - Jan Lieskovsky : [shared] Modify OVAL check for
> accounts_passwords_pam_faillock_deny rule to require exact setting from
> second ex
> 973ab2b - Martin Preisler : Merge pull request #378 from
> iankko/rhel6_audit_privileged_cmds
> 9066343 - Martin Preisler : Merge pull request #376 from
> iankko/rhel6_nodev_nonroot_partitions
> 4546de2 - Jan Lieskovsky : [BugFix] [RHEL/6] Fix remediation script for
> audit_rules_privileged_commands to properly handle also case when m
> e24a208 - Jan Lieskovsky : [RHEL/6]
> mount_option_nodev_nonroot_local_partitions remediation: * Add reboot
> required NOTE per Shawn's recomme
> 236cb35 - Shawn Wells : Merge pull request #377 from
> iankko/rhel7_mismatched_tag
>
> If we enforce tagging PR's with labels, such as "feature" vs "bugfix" we can
> then query based upon that information as well.

Speaking about labels, would it make sense to break them into more fine-grained
level yet (e.g. something like "OVAL check fix", "New remediation", "New OVAL",
"New OVAL for RHEL/7", "New OVAL for Fedora", "Remediation fix", "Common bugfix"
... - covering issues not falling in some of the previous categories).

IMHO these could be helpful when creating such release notes page [1] for
future releases (but on the other hand to keep them in reasonable count).