These files cause problems with Docker images and read-only
directories/mounts, and they have dubious value (any install-time
setup should instead be done at startup).
Rationale:
* Clearing out `src/node_modules` is unlikely to bring future
success.
* If there is an error, it's better to leave the filesystem alone so
that the user can investigate the cause.
* Deleting the directory on error is a surprising behavior.
* cd to top-level Etherpad directory is now more robust.
* Only attempt to update packages whose names begin with `ep_`.
* Don't create `package-lock.json`.
* Improve logging.
* Improve error handling.
Outputs a list of pluginnames and email address for maintainers to contact. Useful for me to bump folks to maintain there stuff and stop it getting stale :)
* docs: fix links from TOC to Headings
* docs: Styling
Just a little modernisation of the appearance of the documentation
* Update src/bin/doc/package.json
Co-authored-by: Richard Hansen <rhansen@rhansen.org>
Co-authored-by: Richard Hansen <rhansen@rhansen.org>
* tests: Restore `runnerBackend.sh`
`runnerBackend.sh` was deleted in commit
7dae5e3db8 but plugins still need it
until their GitHub workflow definitions have been updated.
Co-authored-by: John McLear <john@mclear.co.uk>
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).
