Add release "next" version command #52

Gustry · 2021-04-14T02:28:23Z

This would be convenient on CI, to make a package when it's not based on a "tag", but rather on a commit.
The version must always be lower in the metadata.txt otherwise QGIS Plugin Manager won't notify the user for a new version.

Fix #34

Gustry · 2021-04-28T03:27:17Z

Anything against the git_sha1 and the date_time added ?

It's for traceability, because it's not linked to any tag. Many packages can have the same version otherwise.

If needed, I can add them only if we are in the next command.

Gustry · 2021-04-28T04:06:05Z

Somehow, the new metadata info are not in the final zip when I use it on some plugins.

3nids · 2021-04-28T05:47:47Z

docs/usage/cli_changelog.md

+- When packaging or releasing, you can use these keywords :
+  - `latest` will make a package of the latest tag described in the changelog file.
+  - `next` will make a package of the possible smallest higher tag :
+    - `3.4.0` -> `3.4.1-alpha`


isn't it 3.4.1 ?

qgispluginci/release.py

3nids · 2021-04-28T05:49:40Z

qgispluginci/release.py

+
+    # Date/time in UTC
+    add_in_file(
+        "{}/metadata.txt".format(parameters.plugin_path),


Suggested change

"{}/metadata.txt".format(parameters.plugin_path),

f"{parameters.plugin_path}/metadata.txt",

qgispluginci/utils.py

3nids · 2021-04-28T05:53:52Z

test/test_utils.py

@@ -49,6 +49,22 @@ def test_version_note_from_tag(self):
        self.assertIsNone(version.prerelease)
        self.assertFalse(version.is_prerelease)

+    def test_next_version(self):
+        """ Test to guess the next version. """
+        self.assertEqual(parse_tag("10.1.0").next_version().version, "10.1.1-alpha")


is this because next version is experimental by default?

Gustry · 2021-04-29T02:13:55Z

3.4.0 -> 3.4.1-alpha

Yes it is expected, to be the "smallest higher version", so by adding any pre-release string.

Timeline with this PR, the next makes 3.4.1-alpha:
- t+0, you tag 3.4.0, the changelog contains 3.4.0
- t+1, you start working for the next version, the CI will release 3.4.1-alpha
- t+2, you continue working, the CI will release 3.4.1-alpha
- t+3, you have finished this new version, you tag 3.4.1, QGIS will notify all users about the new version, including the one who you used the artifact from CI
Timeline if the next makes 3.4.1:
- t+0, you tag 3.4.0, the changelog contains 3.4.0
- t+1, you start working for the next version, the CI will release 3.4.1
- t+2, you continue working, the CI will release 3.4.1
- t+3, you have finished this new version, you tag 3.4.1, QGIS will notify only users from the tag 3.4.0. Users which have downloaded the artifact from CI 3.4.1 won't be warned by QGIS about the new tagged version.

This is based on some previous experiences with the QGIS Plugin Manager and some users who you have downloaded artifact. They forgot to come back to a normal "tagged" version because the Plugin Manager in QGIS was not notifying them until we make a higher proper tag.

I'm aware that it looks fragile for now. Of course I'm happy to have a better solution. It's just how QGIS Plugin manager works for now to notify new versions.

I hope I was clear :)

Guts · 2021-04-29T07:11:55Z

I'm not sure that it's a good idea to make the next version experimental by default.

How to pick the type of pre-release? If I just want a beta or directly a release candidate or a post, can I do it?

We're speaking about the conventional, nearly standardized, semantic versioning so I think it would be better to implement it cleanly and work on QGIS Plugins Manager to make it fit also the convention, instead of keep stucked on a irregular implementation. No?

Guts · 2021-04-29T07:14:54Z

Anything against the git_sha1 and the date_time added ?

It's for traceability, because it's not linked to any tag. Many packages can have the same version otherwise.

If needed, I can add them only if we are in the next command.

I don't see the related commit. Can you link to the lines of code please?

Not sure that it's a shared expectation so maybe it's better to use it only with this next command.

Gustry · 2021-04-29T11:53:07Z

I'm not sure that it's a good idea to make the next version experimental by default.

Hum, you mean that for zip package, we shouldn't set the "experimental" flag in the metadata.txt ?
Maybe true, it depends how you install it. Mostly, users will install it from the ZIP file, so QGIS Plugin manager doesn't care about "experimental flag". But if you set up a customs plugins.xml, indeed, maybe it would be a problem for some users.

How to pick the type of pre-release? If I just want a beta or directly a release candidate or a post, can I do it?

If your last tag in the changelog is a RC and in the CLI you ask a next version with alpha, what will do qgis-plugin-ci ?
That's why I did the full-auto way for me.

We're speaking about the conventional, nearly standardized, semantic versioning so I think it would be better to implement it cleanly and work on QGIS Plugins Manager to make it fit also the convention, instead of keep stucked on a irregular implementation. No?

Sorry, I don't understand. Everything is following semantic versioning here. QGIS is also following this convention.
What do you want to implement in QGIS ? A proper way to have continuous release of a plugin ?
@Guts The plugin manager handle well semantic versioning : https://github.com/qgis/QGIS/blob/master/python/pyplugin_installer/version_compare.py

Not sure that it's a shared expectation so maybe it's better to use it only with this next command.

Sure, I though about that, then I thought it doesn't bother to have this info in the metadata.txt. I can make the PR in QGIS documentation to add them : https://docs.qgis.org/testing/en/docs/pyqgis_developer_cookbook/plugins/plugins.html#plugin-metadata I can change that if needed.

For the code, look gitSha1 or dateTime. I have renamed to follow the convention in the metadata.txt which use lower camelcase for keys.

3nids · 2022-03-17T05:48:39Z

What's up here?

Gustry · 2022-03-17T08:29:09Z

I want to come back on it. Some code from this PR is in the new one #119

Gustry · 2023-10-10T14:53:47Z

Let's close it even if I'm still missing this feature.
I'm still impacted by this lack but I have some bash command in the CI script to overpass this PR in the meantime :

if [ -z "$CI_COMMIT_TAG" ]
then
  TAG=$(git describe --tags $(git rev-list --tags --max-count=1))
  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
  echo "VERSION=${VERSION}" > build.env
  echo "STATUS=unstable" >> build.env
else
  echo "VERSION=${CI_COMMIT_TAG}" > build.env
  echo "STATUS=stable" >> build.env
fi

Gustry · 2023-10-10T14:55:07Z

branch moved to my own fork for archive

Gustry force-pushed the next_version branch 2 times, most recently from 6f08efd to 0295331 Compare April 28, 2021 03:23

Gustry marked this pull request as ready for review April 28, 2021 03:23

Gustry requested review from Guts and 3nids and removed request for Guts April 28, 2021 03:27

Gustry mentioned this pull request Apr 28, 2021

Keep a Changelog : Unreleased and subsections #56

Open

Gustry changed the title ~~Add release next version command~~ Add release "next" version command Apr 28, 2021

Gustry force-pushed the next_version branch from 0295331 to ea2c749 Compare April 28, 2021 04:05

3nids reviewed Apr 28, 2021

View reviewed changes

qgispluginci/release.py Outdated Show resolved Hide resolved

3nids reviewed Apr 28, 2021

View reviewed changes

qgispluginci/utils.py Outdated Show resolved Hide resolved

3nids reviewed Apr 28, 2021

View reviewed changes

qgispluginci/utils.py Outdated Show resolved Hide resolved

3nids reviewed Apr 28, 2021

View reviewed changes

Gustry force-pushed the next_version branch from ea2c749 to c755015 Compare April 29, 2021 02:29

Gustry force-pushed the next_version branch from c755015 to 4ed481e Compare May 10, 2021 05:57

Gustry force-pushed the next_version branch from f0c1abd to 06174a3 Compare September 27, 2021 18:59

Gustry marked this pull request as draft September 27, 2021 18:59

Gustry force-pushed the next_version branch 2 times, most recently from f4f775b to c8fd893 Compare March 17, 2022 13:10

Add release next version command

fb35466

Gustry force-pushed the next_version branch from 2805b19 to fb35466 Compare March 17, 2022 13:14

Gustry closed this Oct 10, 2023

Gustry deleted the next_version branch October 10, 2023 14:55

Gustry mentioned this pull request Mar 4, 2024

Validate (at least some) args #251

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add release "next" version command #52

Add release "next" version command #52

Gustry commented Apr 14, 2021 •

edited

Gustry commented Apr 28, 2021

Gustry commented Apr 28, 2021

3nids Apr 28, 2021 •

edited

3nids Apr 28, 2021

3nids Apr 28, 2021

Gustry commented Apr 29, 2021

Guts commented Apr 29, 2021

Guts commented Apr 29, 2021

Gustry commented Apr 29, 2021

3nids commented Mar 17, 2022

Gustry commented Mar 17, 2022

Gustry commented Oct 10, 2023

Gustry commented Oct 10, 2023

	"{}/metadata.txt".format(parameters.plugin_path),
	f"{parameters.plugin_path}/metadata.txt",

Add release "next" version command #52

Add release "next" version command #52

Conversation

Gustry commented Apr 14, 2021 • edited

Gustry commented Apr 28, 2021

Gustry commented Apr 28, 2021

3nids Apr 28, 2021 • edited

Choose a reason for hiding this comment

3nids Apr 28, 2021

Choose a reason for hiding this comment

3nids Apr 28, 2021

Choose a reason for hiding this comment

Gustry commented Apr 29, 2021

Guts commented Apr 29, 2021

Guts commented Apr 29, 2021

Gustry commented Apr 29, 2021

3nids commented Mar 17, 2022

Gustry commented Mar 17, 2022

Gustry commented Oct 10, 2023

Gustry commented Oct 10, 2023

Gustry commented Apr 14, 2021 •

edited

3nids Apr 28, 2021 •

edited