5.1.0 release notes: updated synopsis

[agh1]

Overview

I forgot to fill the synopsis when writing the 5.1.0 release notes.

Before

The synopsis is empty.

After

The synopsis has information on the release.

[totten]

@agh1 @guanhuan - I just noticed a discrepancy in how the release notes are linked. Arguably, I shouldn't have merged this into master. For the moment, I've resolved by cherry-picking and applying to 5.1.

However, let me describe the situation a little more (and maybe we can figure out something simpler.) The 5.1.0.md notes exist in a few places -- e.g.

• master branch (which covers any future releases derived therefrom, e.g. 5.3.0 or 5.3.1, 5.4.0, ...)
• 5.2 (rc) branch (which covers any future releases derived therefrom, e.g. 5.2.0 or 5.2.1; changes in 5.2 propagate to master)
• 5.1 (stable) branch (which covers any future releases derived therefrom, e.g. 5.1.1 or 5.1.2)
• 5.1.0 tag (i.e. the release that went out last Wed)

The way in which we handle corrections to the release notes determines a few things:

• Which future tarballs will (or won't) include the corrected notes?
• Which URLs will (or won't) lead to the corrected notes?

One simple change that mitigates the URL concern is to hyperlink to the redirector (e.g. http://download.civicrm.org/about/5.1.0). The in-app footer does this now, and we could update the blogs to use the same. However, it's not a complete fix because there's still the question about future release tarballs having the corrected notes.

There are a couple ways we could handle corrections to release notes:

• (a) Use the same workflow as a critical-patch. First, patch the RC branch (currently 5.2); the dev-team will eventually merge RC=>master. Since the notes necessarily apply to 5.1, also backport to 5.1.
• (b) Move the release notes to a separate repo with one evergreen branch. We can either (a, easy-option) add a hyperlink from the tarball's README to the evergreen branch or (b, slightly-harder-option) update the build system to copy notes into the tarball.
• (c) Shrug it off. It doesn't much matter if there are a few variants on the notes floating around.

I like how (a) is consistent with the coding workflow -- and (going forward) I can remind myself that "release-notes are like critical-patches". However, it is a bit counter-intuitive that a correction which is about 5.1.0 starts out as a patch to 5.2. If you can live with that, @agh1, then I can live with that.

[agh1]

@totten this makes perfect sense. I'll try to remember to open any last-minute changes like this against the RC branch and expect whoever merges it to then merge to the active version branch and to master.

(I don't see it as necessarily counter-intuitive because the 5.1.0 release notes' audience may well be the person who upgrades straight from 4.7.20-something to 5.2.0 and wants to see what's in the several versions in between.

[guanhuan]

Sounds like a good solution. Thanks @totten!

cc @mi-kon