The plugin updater would previously stumble over compat spec version
entries that begin with angled brackets.
````
< 3.3.0.beta1-dev: 56b0de3896361b6a87523537c8f5b450d2fe0807
3.2.0: 33c43ca51ac7b7baa8a309a269dcf8685b8bd638
< 3.2.0.beta2-dev: ac930c509e2a5b0c37b84bcea28d332e686add95
3.1.999: a304cd2028ccf1f5b00f5137633aa7027a1fd334
3.1.0.beta3: 9c270cac9abc1c2b30574d8c655fb3a90546236b
[...]
````
The update.py script would error out if the spec had a trailing new
line. The split that follows it would try to split it into two, and
error out as it can't.
...in the update script and remove it from the Gemfile.lock. Having
it there causes a failure with the error message:
Could not find libv8-node-16.10.0.0-aarch64-linux in any of the
sources (Bundler::GemNotFound)
And since we're not using the prebuilt binary packages anyway, we
don't need it there in the first place.
Add a DiscourseVersion class which handles Discourse's version
numbering properly when sorting - beta versions are sorted lower than
their respective release versions. It can also return both its version
number and equivalent git tag, removing the need for `rev2version` and
manually adding `v` to the front.
Using DiscourseVersion instead of LooseVersion, we can list all
current version number tags from the `discourse` repo and sort them
correctly, giving us the latest one, regardless of type; i.e. we don't
have to filter for only release versions or beta versions anymore.
This also implements the plugin pinning algorithm laid out here:
https://meta.discourse.org/t/pinning-plugin-and-theme-versions-for-older-discourse-installs/156971
to make sure we don't upgrade plugins further than what's compatible
with our currently packaged Discourse version. While it likely won't
matter much most of the time if we continue packaging the beta
versions, it could be helpful if we decide to go back to packaging
release versions or if we run into issues with future upgrades. In
that case, the plugins could still be updated safely even though we're
not on the latest version of Discourse.
Also, add support for updating plugins which keep gem versions in
files at the root of the repo (discourse-prometheus) and replace the
`up-plugin.sh` script with a README file pointing to the plugin
packaging documentation.
Let the update.py script handle the initial, repetitive task of
packaging new plugins. With this in place, the plugin only needs to be
added to the list in `update-plugins` and most of the work will be
done automatically when the script is run. Metadata still needs to be
filled in manually and some packages may of course require additional
work/patching.