Versioning for Qt Creator plugins in alpha/beta stage

[jesperm]

I'm looking for ideas and inspiration how to handle Qt Creator plugins which is considered to be in in alpha/beta stages.

We are currently using semantic versioning along with pre-release labels to track the maturity of our plugins, for example:

• 1.1.0-alpha.14
• 1.0.0-beta.55

However, the plugin meta data only allows for versions in the format of x.y.z_n (as specified here). We could package the plugin in a installer and assign the installer our version number, but it would be beneficial to see the "actual" version of the plugin directly in Qt Creator.

Have anybody been struggling with this scenario and perhaps found a suitable solution for it?

[jesperm]

This is the solution we plan to go with.

The semantic version will be accessible somewhere in the plugin (“About” button, text element or similar) for development versions (alpha, beta, release candidate, hotfix). This allows us to have a lighter mapping between the semantic version of the build and meta version entered for the plugin.

The version entered in the meta data will set x.y.z based on the semantic version (ignoring the pre-release label). When a development version is built, we append _n to the meta version (where n is an increasing number for each build).

In short
For development builds: x.y.z_n = <sem.major>.<sem.minor>.<sem.patch>_<build number>
For stable builds: x.y.z = <sem.major>.<sem.minor>.<sem.patch>

Edit
We have introduced the usage of GitVersion to determine the version number for our builds. It has a nice feature of delivering a "weighted" number and we use this instead of using a increasing build for development builds (the _n part of the version).

[Christian Ehrlicher]

@jesperm said in Versioning for Qt Creator plugins in alpha/beta stage:

Have anybody been struggling with this scenario and perhaps found a suitable solution for it?

KDE is/was using x.y-1.95 for alpha, x.y-1.96... 99 for betas afair.

[aha_1980]

I'd go with what @Christian-Ehrlicher said.

Qt Creator itself uses this notion, e.g. 4.12.0-beta1 is internally numbered 4.11.82.

Regards

[jesperm]

Thanks for the suggestions/input @Christian-Ehrlicher and @aha_1980!

So I guess this is what I need to do: setup a mapping between our semantic version and a notion which is supported by the plugins (like Qt Creator as you said @aha_1980) when pre-release labels are used.

Is the the rule-set used by Qt Creator internally available to look at?

Creating a mapping for beta releases would be rather easy to create. Our number which is part of the pre-release beta label is increased based on the build-version. For example: 1.0.0-beta.1 would then be 1.0.0_1. The tricky part is that I also need to consider alpha release candidate builds (1.0.0-alpha.2 and 1.0.0-rc.0).

[jesperm]

This is the solution we plan to go with.

The semantic version will be accessible somewhere in the plugin (“About” button, text element or similar) for development versions (alpha, beta, release candidate, hotfix). This allows us to have a lighter mapping between the semantic version of the build and meta version entered for the plugin.

The version entered in the meta data will set x.y.z based on the semantic version (ignoring the pre-release label). When a development version is built, we append _n to the meta version (where n is an increasing number for each build).

In short
For development builds: x.y.z_n = <sem.major>.<sem.minor>.<sem.patch>_<build number>
For stable builds: x.y.z = <sem.major>.<sem.minor>.<sem.patch>

Edit
We have introduced the usage of GitVersion to determine the version number for our builds. It has a nice feature of delivering a "weighted" number and we use this instead of using a increasing build for development builds (the _n part of the version).