So I've been dealing with the SDK for a project I'm working on, and something caught my eye. Namely, the versioning:
This is a float in the format x.y which identifies the version of your plugin. [emphasis added] You should keep this updated whenever you make a new release. Construct 2 uses it to verify projects are compatible when opening. For example, Construct 2 will show a warning if a project was saved with version 2 of a plugin, but is opened with version 1 of the plugin installed.
Using a float is not exactly a great system for versioning. You could consider it as a major.minor scheme, but if compared as a float you can easily lock yourself into having to do new major revisions every 10 updates if you limit yourself to a single decimal (1.8, 1.9, uh oh, 2.0), or at some point if you don't want to increase the major version number you'd end up doing version numbers like 1.992 or so. Not exactly ideal.
As such, I'd like to suggest that Construct 2 switches to semantic versioning for addons. It would remove the pitfalls mentioned earlier, and also bring, well, semantics, to addon versioning. For example:
- Addon Version 0.X.X means that the public API (in Construct 2's case, ACEs and parameters) is still potentially changing in compatibility-breaking ways, and should be used in production with care.
- Addon Version 1.X.X and onwards would have solidified the public API. Any notable changes that break backwards compatibility would warrant a bump in the major version (to 2.X.X and onwards).
- New features that do not break backwards compatibility would bump the minor revision number.
For example: 1.0.0 -> 1.1.0
- Bug fixes and other patches that do not change functionality would simply bump the patch number.
For example: 0.5.12 -> 0.5.13
- Version numbers could go above 9 in each category without breaking parsing (which you can't do with floats - 0.9 would be treated bigger than 0.10 and 0.11, so you'd have to do 0.9 -> 0.91).
And probably the biggest thing: Semantic versioning makes dependency management actually feasible. If your project uses Addon version 1.2.23, then the project should keep working perfectly fine with Addon version 1.X.X, as long as the exact version is above or equal to the one that was used. Construct 2's addon system will hopefully evolve to have project-specific (local) addons eventually, along with a proper addon management system, and semantic versioning would be the solid foundation to build such a system on.
Transitioning to semantic versioning should not be hard either. Existing version numbers in the format X.Y could simply be treated as 0.X.Y until the plugin authors update to actual semantic version numbers.
(As for implementing semantic version parsing in C2, for inspiration here's the semver module that npm, the Node.js package manager, uses. Also, as a sidenote, package management in Node with npm is absolutely fantastic, so following suit with what has been done there most certainly wouldn't hurt.)