Release 1.19.1

[DeeDeeG]

DeeDeeG (1):

• Update dependencies for May 2020 (#622)

[DeeDeeG]

The body of the commit message for this PR should simply be:

Update dependencies for May 2020 (#622)

* dependencies: Update puma and jquery

* dependencies: Bump Kaminari and Rails

[DeeDeeG]

I've mentioned it before, but I'd really like us to merge these release PRs on the command line so the pointer of master just advances forward to meet develop.

What we're doing now:

Before PR:

  -----O------O
 /            ^
O             master
^\
| -----O------O------O------O------O
|                                  ^
common ancestor                    develop

After PR:

  -----O------O------O
 /                   ^
O                    master
^\
| -----O------O------O------O------O
|                                  ^
common ancestor                    develop

In this example, master has advanced by one commit in its own direction, and its history continues to diverge from develop.

What I'd like us to be doing:

Before PR:

O------O------O------O------O
^                           ^
master                      develop

After PR:

O------O------O------O------O
                            ^
                            develop, master ("two branch pointers" aka "two branches", pointing at the same commit)

In the above example, master is now advanced to sync with develop; they are truly two pointers to one and the same commit now. The histories do not diverge, they converge. All is at harmony with the universe. etc. etc. (Okay, that's an exaggeration.) PRs on GitHub.com work like they're supposed to and generally make sense again.

(Edit: "PRs work like they're supposed to" other than having to hop over to command-line to merge the branches. GitHub does not have a UI to make it possible to perform this simple "advance pointer forward on a linear commit history" aka "fast-forward" merge. It wouldn't be hard, they've just apparently chosen not to add the feature to their site.)

I would also see "merge commits into master" as a reasonable alternative. git/GitHub get really confused by the deliberately diverging, squash-and-merge branching strategy. It makes doing anything with master a pain, IMO; luckily we don't do anything to master other than making releases, but... tl;dr releases are a pain.

(Sorry to complain, but I also just wanted to point out what we're doing and see if folks agree with me on the solution or not. Thanks.)