Answers.Body: <p>This is an excellent question. Before trying to answer, let me note a bit of the context:</p>
  
  <ul>
  <li>When defining a test plan, several organizational and technical factors can weigh-in (e.g. perhaps certain extensions or use-cases are more important or more within your expertise; perhaps there's a rotation of responsibilities). The question focused on how to examine the change-list -- that's not the only factor, but it is an important one, so we should have a good answer.</li>
  <li>The RC releases and general releases are lined up on rolling monthly cycles. You can get more specifics by reading <a href="https://lab.civicrm.org/dev/release" rel="noreferrer">the schedule of releases</a>. I usually think about the schedule in reverse (from the release date). For example, <code>v5.3.0</code> will be released at the start of July. The testing period for the RC (<code>v5.3.beta1</code>) is the previous month, June. The development period for <code>v5.3.alpha1</code> is the month before that, May.</li>
  <li>CiviCRM development is managed in Git/Github -- this is where changes are submitted and reviewed. Most reports about changes are derived from this data.</li>
  <li>In a typical monthly cycle, there are 80-150 accepted proposals (aka "PR"s or "pull-requests").</li>
  </ul>
  
  <p>There is no one perfect way to list changes during the RC period, but there are a few tools/techniques available.</p>
  
  <p><strong>Release Notes</strong>: This is a curated document (usually written by Andrew Hunt and Alice Frumin). </p>
  
  <ul>
  <li><strong>Good</strong>: 
  
  <ul>
  <li>The notes are nicer to read and don't require as much technical skill.</li>
  </ul></li>
  <li><strong>Bad</strong>: 
  
  <ul>
  <li>It takes a while to put them together -- so they may not be available until too late.</li>
  </ul></li>
  <li><strong>Examples</strong>: 
  
  <ul>
  <li>For v5.2, the release-notes are tracked under <a href="https://github.com/civicrm/civicrm-core/tree/5.2/release-notes" rel="noreferrer">https://github.com/civicrm/civicrm-core/tree/5.2/release-notes</a></li>
  <li>For v5.3, the release-notes will be tracked under <a href="https://github.com/civicrm/civicrm-core/tree/5.3/release-notes" rel="noreferrer">https://github.com/civicrm/civicrm-core/tree/5.3/release-notes</a></li>
  <li>Once a release is published (e.g. 5.2.0), the long-term/supported URL for the release-notes looks like <a href="http://download.civicrm.org/about/5.2.0" rel="noreferrer">http://download.civicrm.org/about/5.2.0</a></li>
  </ul></li>
  <li><strong>Comments</strong>: 
  
  <ul>
  <li>During the RC period, you might be able to find a draft of the release notes. Look in the <a href="https://github.com/civicrm/civicrm-core/pulls?utf8=%E2%9C%93&amp;q=is%3Apr" rel="noreferrer">PR queue</a> and filter on "Label" (for the given version).</li>
  <li>For more info, chat with <code>@agh1</code> on Mattermost.</li>
  </ul></li>
  </ul>
  
  <p><strong>Github PR Queue</strong>: All changes are proposed in Github by filing a "pull request" (PR).</p>
  
  <ul>
  <li><strong>Good</strong>:
  
  <ul>
  <li>The full list is available when you want it, and it can be loaded in a web-browser.</li>
  </ul></li>
  <li><strong>Bad</strong>:
  
  <ul>
  <li>The filter options aren't good for your use-case. You need to try a few different filters.</li>
  <li>You may need to check multiple repos (<code>civicrm-core</code> is the main one; but sometimes interesting things happen in <code>civicrm-packages</code>, <code>civicrm-drupal</code>, <code>civicrm-wordpress</code>, <code>civicrm-backdrop</code>, <code>civicrm-joomla</code>).</li>
  </ul></li>
  <li><strong>Examples</strong>:
  
  <ul>
  <li><a href="https://github.com/civicrm/civicrm-core/pulls?q=is%3Apr+label%3Amaster+is%3Aclosed" rel="noreferrer">All closed PRs in <code>civicrm-core</code> labeled <code>master</code></a> - These are changes approved during normal development. However, it includes all development phases of all versions. If you're testing <code>5.3.beta1</code>, then focus on items approved during May.</li>
  <li><a href="https://github.com/civicrm/civicrm-core/pulls?utf8=%E2%9C%93&amp;q=is%3Apr+label%3A5.3" rel="noreferrer">All open or closed PRs in <code>civicrm-core</code> labeled <code>5.3</code></a>. These are late-stage corrections proposed or approved during the 5.3 testing period.</li>
  </ul></li>
  <li><strong>Comments</strong>:
  
  <ul>
  <li>We have <a href="https://lab.civicrm.org/infrastructure/gitlab/issues/3" rel="noreferrer">an open issue</a> to improve the infrastructure so that it's easier to filter Github data based the target version ("Milestone").</li>
  </ul></li>
  </ul>
  
  <p><strong>Git</strong>: Every individual change and every PR approval is available in the <code>git</code> database.</p>
  
  <ul>
  <li><strong>Good</strong>:
  
  <ul>
  <li>This is the most accurate and flexible way to filter a change list. It is always up-to-date.</li>
  </ul></li>
  <li><strong>Bad</strong>:
  
  <ul>
  <li>This requires more technical proficiency -- e.g. understanding <code>git</code> and the Unix CLI.</li>
  <li>The text in git is written by many different developers. The text varies a lot in terms of length/language/quality.</li>
  </ul></li>
  </ul>
  
  <p>This is more powerful and more technical, so I want to give a longer discussion of examples. </p>
  
  <p>Git allows you to display developer notes over a range of versions. For example, when studying v5.3, you might to view notes after <code>5.2</code> and before <code>5.3</code>. This range is called <code>5.2..5.3</code> -- or, more specifically, <code>origin/5.2..origin/5.3</code>.</p>
  
  <p>You can review developer notes for the range:</p>
  
  <pre><code># Get a list of all developer notes.
  git log origin/5.2..origin/5.3
  </code></pre>
  
  <p>Additionally, you can filter based on the affected code/subsystem.</p>
  
  <pre><code># Get a list of all developer notes relevant to the table definitions
  git log origin/5.2..origin/5.3 -- xml/schema/
  
  # Get a list of all developer notes relevant to the DB upgrade steps
  git log origin/5.2..origin/5.3 -- CRM/Upgrade/
  
  # Get a list of all developer notes relevant to the "Financial" subsystem
  git log origin/5.2..origin/5.3 -- CRM/Financial templates/CRM/Financial xml/schema/Financial
  
  # Get a list of all developer notes relevant to the APIv3 framework
  git log origin/5.2..origin/5.3 api/ CRM/Utils/API/ Civi/API/
  </code></pre>
  
  <p>All those examples use <code>git log</code> to show developer notes, but the same filters (by range and by folder) can produce other types of output. Compare:</p>
  
  <pre><code># Get a list of developer notes for a folder (as above)
  git log origin/5.2..origin/5.3 -- CRM/Upgrade/
  
  # Get the same list and display it in a GUI tool (on local Linux/OSX workstation)
  gitk origin/5.2..origin/5.3 -- CRM/Upgrade/
  
  # Get the same list and display in short, one-line, summary format
  git log --oneline origin/5.2..origin/5.3 -- CRM/Upgrade/
  
  # Get the same list and include the relevant code changes
  git log -p origin/5.2..origin/5.3 -- CRM/Upgrade/
  
  # Get cumulative diff reflecting all those changes
  git diff origin/5.2..origin/5.3 -- CRM/Upgrade/
  </code></pre>
  
  <p>If you're a CLI guru, then you can do further filtering. This is usually easiest with the <code>--oneline</code> format.</p>
  
  <pre><code># Get a summary list which identifies the approved pull requests
  git log origin/5.2..origin/5.3 --oneline | grep 'Merge pull'
  
  # As above, but only show the PR#
  git log origin/5.2..origin/5.3 --oneline | grep 'Merge pull' | awk '{print $5}'
  
  # As above, but show the URL for each PR
  git log origin/5.2..origin/5.3 --oneline | grep 'Merge pull' | awk '{print $5}' | sed 's;#;https://github.com/civicrm/civicrm-core/pull/;'
  </code></pre>
  
  <p>Of course, there may be other tools, but that's the one I use on a day-to-day basis to examine change history.</p>
  
  <p>(<strong>Update</strong>)
  If this kind of reporting is useful on a regular basis, then you might want to put these commands in a <code>bash</code> script -- then you can quickly re-run the same report. Here is <a href="https://gist.github.com/totten/80ac53730a664a36e374caa50b0f1404" rel="noreferrer">an example of a custom report</a>.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-06-14T00:56:59.613Z
Answers.Text: shame i can only give this +1
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-06-14T00:21:46.740Z
Answers.LastActivityDate: 2018-06-14T02:23:44.657Z
Answers.LastEditDate: 2018-06-14T02:23:44.657Z
Answers.UserDisplayName: Tim Otten
Body: <p>We would like to help test the monthly CiviCRM Release Candidate (RC) versions to contribute to more reliable releases. I found out the RC are published <a href="https://download.civicrm.org/latest" rel="noreferrer">here</a> along with the stable releases, so e.g. when CiviCRM 5.2.0 is released, it's accompanied by a RC for 5.3.0.</p>
  
  <p>Now, in order to do focused and meaningful testing, we need to find out which changes went into the Release Candidate so we know which functionalities we should scrutinize most. Where can we get that information?</p>
  
Tags: <issues><testing><release>
Title: How to find out about changes in the latest Release Candidate?
ThreadText: # How to find out about changes in the latest Release Candidate?
  
  (Asked by: username_0 on 2018-06-13)
  
  We would like to help test the monthly CiviCRM Release Candidate (RC) versions to contribute to more reliable releases. I found out the RC are published [here](https://download.civicrm.org/latest) along with the stable releases, so e.g. when CiviCRM 5.2.0 is released, it's accompanied by a RC for 5.3.0.
  
  Now, in order to do focused and meaningful testing, we need to find out which changes went into the Release Candidate so we know which functionalities we should scrutinize most. Where can we get that information?
  
  **Tags:** issues, testing, release
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-06-14. Score: 9
  
  This is an excellent question. Before trying to answer, let me note a bit of the context:
  
  When defining a test plan, several organizational and technical factors can weigh-in (e.g. perhaps certain extensions or use-cases are more important or more within your expertise; perhaps there's a rotation of responsibilities). The question focused on how to examine the change-list -- that's not the only factor, but it is an important one, so we should have a good answer.
  The RC releases and general releases are lined up on rolling monthly cycles. You can get more specifics by reading the schedule of releases. I usually think about the schedule in reverse (from the release date). For example, v5.3.0 will be released at the start of July. The testing period for the RC (v5.3.beta1) is the previous month, June. The development period for v5.3.alpha1 is the month before that, May.
  CiviCRM development is managed in Git/Github -- this is where changes are submitted and reviewed. Most reports about changes are derived from this data.
  In a typical monthly cycle, there are 80-150 accepted proposals (aka "PR"s or "pull-requests").
  
  There is no one perfect way to list changes during the RC period, but there are a few tools/techniques available.
  Release Notes: This is a curated document (usually written by Andrew Hunt and Alice Frumin). 
  
  Good: 
  
  
  The notes are nicer to read and don't require as much technical skill.
  
  Bad: 
  
  
  It takes a while to put them together -- so they may not be available until too late.
  
  Examples: 
  
  
  For v5.2, the release-notes are tracked under https://github.com/civicrm/civicrm-core/tree/5.2/release-notes
  For v5.3, the release-notes will be tracked under https://github.com/civicrm/civicrm-core/tree/5.3/release-notes
  Once a release is published (e.g. 5.2.0), the long-term/supported URL for the release-notes looks like http://download.civicrm.org/about/5.2.0
  
  Comments: 
  
  
  During the RC period, you might be able to find a draft of the release notes. Look in the PR queue and filter on "Label" (for the given version).
  For more info, chat with @agh1 on Mattermost.
  
  
  Github PR Queue: All changes are proposed in Github by filing a "pull request" (PR).
  
  Good:
  
  
  The full list is available when you want it, and it can be loaded in a web-browser.
  
  Bad:
  
  
  The filter options aren't good for your use-case. You need to try a few different filters.
  You may need to check multiple repos (civicrm-core is the main one; but sometimes interesting things happen in civicrm-packages, civicrm-drupal, civicrm-wordpress, civicrm-backdrop, civicrm-joomla).
  
  Examples:
  
  
  All closed PRs in civicrm-core labeled master - These are changes approved during normal development. However, it includes all development phases of all versions. If you're testing 5.3.beta1, then focus on items approved during May.
  All open or closed PRs in civicrm-core labeled 5.3. These are late-stage corrections proposed or approved during the 5.3 testing period.
  
  Comments:
  
  
  We have an open issue to improve the infrastructure so that it's easier to filter Github data based the target version ("Milestone").
  
  
  Git: Every individual change and every PR approval is available in the git database.
  
  Good:
  
  
  This is the most accurate and flexible way to filter a change list. It is always up-to-date.
  
  Bad:
  
  
  This requires more technical proficiency -- e.g. understanding git and the Unix CLI.
  The text in git is written by many different developers. The text varies a lot in terms of length/language/quality.
  
  
  This is more powerful and more technical, so I want to give a longer discussion of examples. 
  Git allows you to display developer notes over a range of versions. For example, when studying v5.3, you might to view notes after 5.2 and before 5.3. This range is called 5.2..5.3 -- or, more specifically, origin/5.2..origin/5.3.
  You can review developer notes for the range:
  # Get a list of all developer notes.
  git log origin/5.2..origin/5.3
  
  Additionally, you can filter based on the affected code/subsystem.
  # Get a list of all developer notes relevant to the table definitions
  git log origin/5.2..origin/5.3 -- xml/schema/
  
  # Get a list of all developer notes relevant to the DB upgrade steps
  git log origin/5.2..origin/5.3 -- CRM/Upgrade/
  
  # Get a list of all developer notes relevant to the "Financial" subsystem
  git log origin/5.2..origin/5.3 -- CRM/Financial templates/CRM/Financial xml/schema/Financial
  
  # Get a list of all developer notes relevant to the APIv3 framework
  git log origin/5.2..origin/5.3 api/ CRM/Utils/API/ Civi/API/
  
  All those examples use git log to show developer notes, but the same filters (by range and by folder) can produce other types of output. Compare:
  # Get a list of developer notes for a folder (as above)
  git log origin/5.2..origin/5.3 -- CRM/Upgrade/
  
  # Get the same list and display it in a GUI tool (on local Linux/OSX workstation)
  gitk origin/5.2..origin/5.3 -- CRM/Upgrade/
  
  # Get the same list and display in short, one-line, summary format
  git log --oneline origin/5.2..origin/5.3 -- CRM/Upgrade/
  
  # Get the same list and include the relevant code changes
  git log -p origin/5.2..origin/5.3 -- CRM/Upgrade/
  
  # Get cumulative diff reflecting all those changes
  git diff origin/5.2..origin/5.3 -- CRM/Upgrade/
  
  If you're a CLI guru, then you can do further filtering. This is usually easiest with the --oneline format.
  # Get a summary list which identifies the approved pull requests
  git log origin/5.2..origin/5.3 --oneline | grep 'Merge pull'
  
  # As above, but only show the PR#
  git log origin/5.2..origin/5.3 --oneline | grep 'Merge pull' | awk '{print $5}'
  
  # As above, but show the URL for each PR
  git log origin/5.2..origin/5.3 --oneline | grep 'Merge pull' | awk '{print $5}' | sed 's;#;https://github.com/civicrm/civicrm-core/pull/;'
  
  Of course, there may be other tools, but that's the one I use on a day-to-day basis to examine change history.
  (Update)
  If this kind of reporting is useful on a regular basis, then you might want to put these commands in a bash script -- then you can quickly re-run the same report. Here is an example of a custom report.
  
  > **Comments:**
  > **username_2**: shame i can only give this +1  
  
  ---
  
  