Describe the bug
You haven't added git tags yet, but the official release is still on the horizon, on 02.01.2023...So this may be superfluous. But judging from the installation manuals, you expect people to clone and update your plugin on the server. (For one, some servers don't have git installed on the production server)
Please consider releasing concrete versions using git tags.
Expected behaviour
You add git tags when you release updated versions of your plugin, best would be to use some kind of semantic versioning, e.g. 1.1.0 or 3.11-1.2.0 or something like that. This way, the server admin can control when to update the plugin instead of being at the "mercy" of branch commits or having to document deployed versions with "gitid: asf71h84578125676056..."
Describe the bug You haven't added git tags yet, but the official release is still on the horizon, on 02.01.2023...So this may be superfluous. But judging from the installation manuals, you expect people to clone and update your plugin on the server. (For one, some servers don't have git installed on the production server) Please consider releasing concrete versions using git tags.
Expected behaviour You add git tags when you release updated versions of your plugin, best would be to use some kind of semantic versioning, e.g. 1.1.0 or 3.11-1.2.0 or something like that. This way, the server admin can control when to update the plugin instead of being at the "mercy" of branch commits or having to document deployed versions with "gitid: asf71h84578125676056..."