libretic/etherpad-lite
6
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

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

Browse source 
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).
This commit is contained in:
Richard Hansen 2021-02-15 13:15:00 -05:00 committed by John McLear
parent e1dcaa5210
commit 8155d6154d
1 changed files with 0 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
src/bin/release.js
View file

@ -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');