[Bug] url mismatch downloading addons for 7.8 dev release on Windows

[nilason]

Describe the bug

Trying to install addons with 7.8 developer release from eg. https://wingrass.fsv.cvut.cz/grass78/x86_64/osgeo4w/ fails.

It tries to download from: https://wingrass.fsv.cvut.cz/grass78/x86_64/addons/grass-7.8.6dev/
but the actual location is: https://wingrass.fsv.cvut.cz/grass78/x86_64/addons/grass-7.8.dev/.

To Reproduce

1. Download a daily 7.8 release binary
2. Try install any addon with g.extension

System description (please complete the following information):

• Operating System: Windows
• GRASS GIS version: 7.8.6dev

Additional context
This may be addressed by either changing the url on server, or in code in g.extension.py.

[wenzeslaus]

I have also recently noticed that we have this inconsistency in 7.8.dev/7.8dev/7.8.6dev. grass --config version for releasebranch_7_8 reports 7.8.6dev, but elsewhere we use 7.8 with some dev after it.

It is not a surprise that Python has a PEP for version numbers (PEP 440) as well a package (versioneer) which covers non-released versions too (similarly to git describe --tags --dirty --always), but right now, I don't know how to directly apply any of it here.

[neteler]

I have also recently noticed that we have this inconsistency in 7.8.dev/7.8dev/7.8.6dev. grass --config version for releasebranch_7_8 reports 7.8.6dev, but elsewhere we use 7.8 with some dev after it.

Yes, we are rather inconsistent here, compare:

https://github.com/OSGeo/grass/blob/releasebranch_7_8/include/VERSION
https://github.com/OSGeo/grass/blob/releasebranch_8_0/include/VERSION
https://github.com/OSGeo/grass/blob/main/include/VERSION

We should decide this and document it in doc/howto_release.md.

[wenzeslaus]

For example, git describe --tags (--tags to get the unannotated tags, too) for releasebranch_7_8 returns 7.8.6-11-gc4dcac886 (g is for Git, c4dcac8 is the current commit short hash, 11 is number of commits since the 7.8.6 tag). Git approach is last tag/version plus somehow suggesting further modifications. Combining this with our current approach, this would result in something like 7.8.6-dev for the state between 7.8.6 and 7.8.7.

PEP 440 Developmental releases has X.Y.devN for a development release of an upcoming X.Y release. In our case, this would be like using 7.8.6.dev before the 7.8.6 release.

Given that we create the release from the major-minor branch (and not from a dedicated major-minor-patch/major-minor-micro branch), it makes sense to me that the full version number of the upcoming release is included together with a dev suffix (7.8.6dev, 7.8.6.dev, 7.8.6-dev). This could apply to all release branches.

This could be applied even to the main branch where the upcoming release is simply the one which will be eventually branched out including 0 as patch/micro version number (so now it would be 8.2.0dev or 8.1.0dev). Applying this logic to the main branch would remove the odd-even release numbering, i.e., the odd numbers would not have to be reserved for the development version. On the other hand, strictly applying the "odd minor version number is development" logic, there is no need for dev suffix on main because that's what the odd minor version number says already. In any case, zero can be added as patch/micro version number on the main branch to align with the release branches.

[neteler]

What we currently have:

==> grass72_release/include/VERSION <==
7
2
4svn
2018

==> grass74_git/include/VERSION <==
7
4
5dev
2019

==> grass74/include/VERSION <==
7
4
5svn
2019

==> grass76_git/include/VERSION <==
7
6
2dev
2020

==> grass78/include/VERSION <==
7
8
7dev
2022

==> grass80/include/VERSION <==
8
0
dev
2022

==> grass_main/include/VERSION <==
8
1
dev
2022

--> Seems that grass80/include/VERSION isn't right (should be 8.0.0dev), right?

[nilason]

Seems that grass80/include/VERSION isn't right (should be 8.0.0dev), right?

I'd say, 8.0.0dev would be the logical for releasebranch_8_0, and 8.1.0dev for main. That way it will be consistent when we bump with a patch release.
MAJOR.MINOR.PATCH[RC1|dev|...]

[echoix]

Is the issue still relevant today? It's grass7.8, so it could be unfixed as the version is out of support (I can't find the exact document that states that decision, as is written for python versions support).

[landam]

I tested latest 7.8.8dev build and installed addons succesfully

[echoix]

Great thanks! Another issue closed! As you see I'll be going through existing issues and PRs in the following weeks, and we'll manage to reduce the backlog!

[landam]

Great thanks! Another issue closed! As you see I'll be going through existing issues and PRs in the following weeks, and we'll manage to reduce the backlog!

Thanks a lot for your effort!