Package of a dev / unstable / master release of a plugin

[ponceta]

I did not find how to package (not release) a dev or master version of a plug.

The error message is confusing because it proposes to use a '--no-validation' flag which seems to be unsupported by the package command.

Run VERSION=master
  
WARNING:root:Be aware that 'master' is not a semver-compliant version. It might still comply with acceptable practices.
Traceback (most recent call last):
  File "/opt/hostedtoolcache/Python/3.12.7/x64/bin/qgis-plugin-ci", line 8, in <module>
    sys.exit(cli())
             ^^^^^
  File "/opt/hostedtoolcache/Python/3.12.7/x64/lib/python3.12/site-packages/qgispluginci/cli.py", line [16](https://github.com/QGEP/qgepplugin/actions/runs/11435702060/job/31811603689#step:6:17)3, in cli
    Parameters.validate_args(args)
  File "/opt/hostedtoolcache/Python/3.12.7/x64/lib/python3.12/site-packages/qgispluginci/parameters.py", line 304, in validate_args
    raise ValueError(
ValueError: 
            Unable to validate the release version 'master'.
            Please use a release version identifier such as '1.0.1' (recommended, semantic versioning), 'v1.1.1', 'v1.1', or '1.1'.
            Otherwise you can disable validation by running this command again with an extra '--no-validation' flag.
            Semantic versioning (semvar) identifiers are recommended.
            Take a look at https://en.wikipedia.org/wiki/Software_versioning#Semantic_versioning for a refresher."
        
Error: Process completed with exit code 1.

[Gustry]

The error message is confusing because it proposes to use a '--no-validation' flag which seems to be unsupported by the package command.

This is a bug I think, the flag should exist in both commands.

But related to naming a version master, it's dangerous IMHO for many end users. The QGIS Plugin manager will not warn at all new version of the plugin. So use this flag only if you know your users and you ask them explicitly to "reinstall the plugin later", otherwise, they will keep this plugin version for "months, years" ;-)

[ponceta]

I'll recommend using dev or unstable keywords then. But in our case it is mostly to ease the package of a plugin with submodule which can be a bit tricky to test for some users.

I used qgis-plugin-ci>=2.8.6 for my test.

[Gustry]

According to the new title :

I'll recommend using dev or unstable keywords then.

It's the same result for the QGIS plugin manager, when it's not following semantic versioning https://semver.org/

Whatever the version not following semantic versioning, QGIS plugin manager has no way to know if version=dev is higher or lower than version 2.34.2, so it won't propose any update to the user.

[Guts]

+1 with @Gustry. Alternatively, you can use a calver verisoning scheme also I guess (not sure).

Why not something semver compliant like X.y.z-dev where X.y.z are obviously your version number?

[ponceta]

Actual workaround would be to have a 0.0.0-dev version so it automatically replaced by a newer version when updating.

Some other usefull thing would be to pass the experimental tag when dealing with pull request or master branch packages

[Gustry]

Some other usefull thing would be to pass the experimental tag when dealing with pull request or master branch packages

It's already done for us.
QGIS-Plugin-CI takes care of parsing your version. For instance X.Y.Z-beta will be experimental. (alpha, beta, rc). You can deal with it in your CI process.

We do one bash line which is not very readable :) :

      - name: Set env
        run: |
          TAG=$(git describe --tags $(git rev-list --tags --max-count=1))
          echo "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}')-alpha" >> $GITHUB_ENV