Add version info for the plugin
m4gr3d opened this issue · comments
Since it's likely the plugin will iterate faster than the Godot releases, we should include versioning information to allow users to differentiate between successive releases.
@timoschwarzer The current version can be 1.0.0 since that's its first(!) release as a standalone plugin.
In addition, we can use gradle's setProperty for the archivesBaseName property to update the generated .aar filename automatically.
Should the version be dependent of Godot's version? Or on Godot's Android plugin version (v1)?
If different Godot versions might require different plugin versions, I think this should be featured somehow in the version string.
I'd opt for <godot version>-<plugin revision for that godot version>, e.g. 3.2.2-stable-1, 3.2.2-stable-2 and so on. That makes it clear which version to use for the users and guarantees API compatibility between the plugin and Godot for a specific version.
You might have seen that I created releases named after the Godot version. E.g. plugin version 3.2.2-stable was built against the 3.2.2-stable godot-lib AAR.
I'd suggest maybe leaving out the -stable suffix, even on the main Godot repo we don't tag pre-release versions which are not formal releases.
The main issue with a numbering like 3.2.2-stable-1 or 3.2.2-1 (aside from not being very readable), is that it would force us to make new releases for every Godot release, even if the current state of the plugin might be compatible with Godot 3.2.3, 3.2.4 or possibly even 4.0.
Another way I could imagine is having a separate versioning scheme (e.g. semver) and documenting the compatible Godot versions in the release description. What do you think about that?
Another way I could imagine is having a separate versioning scheme (e.g. semver) and documenting the compatible Godot versions in the release description. What do you think about that?
I prefer that approach! Since this plugin is also dependent on the latest stable version of the Google Android Billing library, trying to include all that information in the version name will make it unreadable.
Adopting a separate semver versioning scheme will remove that issue.
Then I'll do that tomorrow :)