release: Don't create `release/x.y.z` branch

Patch-specific release branches should never diverge from the tag, so
they serve no useful purpose. (If they do diverge, which some did
before I deleted them all, what does it mean? Are we going to move the
tag in the future? It's just too confusing.)

In the future we might want to do major- or minor-specific
branches (e.g., `release/1` or `release/1.8`), but only if we want to
maintain old releases. For example, if 2.0 is a major release that
doesn't work with plugins designed for 1.x we might want to maintain a
`release/1` branch that continues to get bugfixes while the bulk of
new work continues to land on `develop`. If we do decide to maintain
old releases we'll need a new set of release scripts (or edit the
`release.js` script on the `release/1` branch).

src/bin/release.js

@@ -52,11 +52,9 @@ fs.writeFileSync('src/package.json', JSON.stringify(packageJson, null, 2));
 childProcess.execSync('npm install --package-lock-only', {cwd: 'src/'});
 // run npm install --package-lock-only <-- required???
 
-childProcess.execSync(`git checkout -b release/${newVersion}`);
 childProcess.execSync('git add src/package.json');
 childProcess.execSync('git add src/package-lock.json');
 childProcess.execSync('git commit -m "bump version"');
-childProcess.execSync(`git push origin release/${newVersion}`);
 
 
 childProcess.execSync('make docs');