Implement a "qgis-plugin-ci package next" command

[Gustry]

On a plugin, I'm doing some continuous deployment of the zip package (without any tag), just on every commit.

But QGIS Plugin manager doesn't appreciate if there isn't a proper semver number. QGIS will not raise any warning and propose any plugin update if the version is not following what is used in plugins.qgis.org. This is dangerous because users might stay with an outdated version of the plugin for ever ! (and I must ask my client to explicitely reinstall the plugin to make him upgrade)

So in a gitlab-ci file, I did :

# Get the last tag available (3.2.1 for instance)
TAG=$(git describe --tags $(git rev-list --tags --max-count=1))

# Increment the last minor version and add -beta, 3.2.1 => 3.2.2-beta
VERSION=$(echo ${TAG} | awk -F. -v OFS=. 'NF==1{print ++$NF}; NF>1{if(length($NF+1)>length($NF))$(NF-1)++; $NF=sprintf("%0*d", length($NF), ($NF+1)%(10^length($NF))); print}')-beta
qgis-plugin-ci package ${VERSION}  # 3.2.2-beta

Not a very human readable command :) But at least, I'm sure that whatever the release on plugins.qgis.org later, QGIS will propose the update of the plugin (to 3.2.2 for instance)

Similar to #33, I was thinking to implement qgis-plugin-ci package next, next would be a special keyword to take the last known version in the changelog.md and increment it the same way as above. Maybe use -alpha or -pre instead of -beta

@Guts What do you think ?

[Guts]

It sounds to me like a good idea :+1:.

Some thoughts:

• handle semver prefixed or not by v
• handle an option to set the suffix:
  • if nothing, bump the patch
  • if "suffix=beta" then bump the -beta or switch from alpha to beta, etc.
• consider using the ## [Unreleased] section of https://keepachangelog.com/
• if semver is an official requirements on the QGIS side, I think this project should follow this and support the dev user on the workflow (warnings about no semver friendly version number, etc). So, your idea really fits with this guideline.

[Gustry]

Thanks for your inputs

[Gustry]

It would be good to add the git sha, not for the version, but at least somewhere in the metadata.txt

Initial metadata.txt, in git repo, following the example above https://github.com/opengisch/qgis-plugin-ci/issues/34#issue-805122303, after a tag 3.2.1. I set the version to the name of branch : dev, master etc

version=master

After qgis-plugin-ci

version=3.2.2-beta
git_sha1=1c002d6d

Date/time of packaging would help tracking a ZIP produced not with a tag.

[Gustry]

handle semver prefixed or not by v

Done in #55

handle an option to set the suffix:

Not done. I think it's too risky for the plugin manager and users. The idea of this command is to generate the "smallest higher version". I want to be sure that QGIS Plugin manager will notify users in 99%. The risk is that a developer will tag the same version of the next version already produced earlier by the CI, QGIS won't notify users).

So this command is not touching to the "prerelease" string, only adding numbers.

consider using the ## [Unreleased] section of https://keepachangelog.com/

CF #56