schéma de versions pour mapstore2-georchestra

[Landry Breuil]

Bonjour,

petit sujet sémantique, actuellement les versions du projet
mapstore2-georchestra sont de la forme 2024.02.00-geOrchestra. Je ne
sais pas si c'est actuellement clair pour tout le monde, donc je vais
tenter de l'expliciter:

2024.02 correspond a la version de la 'branche stable' de mapstore
suivie, eg https://github.com/geosolutions-it/MapStore2/commits/2024.02.xx/

.00-geOrchestra correspond a 'la première version du projet
mapstore2-georchestra' de cette branche.

le projet mapstore 'upstream' sort de son coté des versions depuis cette
branche, ex
https://github.com/geosolutions-it/MapStore2/releases/tag/v2024.02.02
https://github.com/geosolutions-it/MapStore2/releases/tag/v2024.02.01
https://github.com/geosolutions-it/MapStore2/releases/tag/v2024.02.00

seul hic, lors d'une 'release' de mapstore2-georchestra (ex
2024.02.00-geOrchestra, cf
https://github.com/georchestra/mapstore2-georchestra/releases/tag/2024.02.00-geOrchestra),
il n'y a pas cohérence des versions 'micro', eg le 00 ne correspond pas
a la version 2024.02.00 du projet upstream, mais 'a un commit donné au
moment de la mise a jour du sous-module mapstore dans le projet
mapstore2-georchestra'. En l’occurrence, pour 2024.02.00-geOrchestra, a
un commit 'plus récent que celui ayant servi a la version 2024.02.02 de
mapstore upstream'.

Pour ma part, étant habitué a ce fonctionnement, ça ne me pose pas de
problème, mais je comprends que ça peut être perturbant, surtout quand
on se réfère a des documentations versionnées, ou qu'on cherche a savoir
si la version qu'on utilise comprend bien telle correction.

après discussion au sein du copil du partenariat de financement des maj
de ce projet dans le temps long (pour lequel nous accueillons toujours
des financeurs !), nous proposons de modifier le schéma de version pour
utiliser 2024.02-geOrchestra.00 pour éviter cette confusion.

De ce numéro de version, on sait qu'on suit une branche donnée, et que
chaque 'micro' release (2024.02-geOrchestra.01, 2024.02-geOrchestra.02)
correspond a une autre maj du sous-module mapstore (ou une correction
changement de configuration spécifique au projet mapstore2-georchestra).
Et dans tous les cas, les notes de versions spécifient bien quels
tickets sont inclus dans une release.

Les versions de mapstore2-georchestra étant complètement décorrélées de
celles de geOrchestra, il n’apparaît pas nécessaire de complexifier le
sujet en ajoutant la version de geOrchestra (24.0, 23.0..) dans l'équation..

en espérant que ça puisse clarifier les choses, ou donner lieu a des
réactions/corrections..
--
Landry Breuil

[Jean Pommier]

Salut Landry,

Oui, ça me semble plus clair comme ça (2024.02-geOrchestra.00). 

Ca fait un peu version à la Ubuntu par contre ;o), mais bon...

Jean Pommier -- pi-Geosolutions

Ingénieur, consultant indépendant

Tél. : (+33) 6 09 23 21 36
E-mail : j...@pi-geosolutions.fr
Web : www.pi-geosolutions.fr
linkedin : jean-pommier

[Julien Sabatier]

Quitte à revoir le versioning, je suggère un truc du genre : 1.0.0+mapstore.2024.02

Ce format est plus proche de recommandations du standard semver : https://semver.org/lang/fr/

En revanche cela implique une montée en version de ms2-geor à chaque nouvelle intégration de version de MS2, mais ça me parait logique.

Cordialement

Julien SABATIER

[Florian Necas]

J'ai créé un ticket par rapport à la réorganisation de la codebase georchestra. https://github.com/georchestra/georchestra/issues/4470

J'aime beaucoup l'idée de Julien mais je modifierait en upstream-georchestraSpecific+georchestraCore, ce qui donnerai 2024.01.00-01+24.0

C'est un peu long mais ça couvre un peu tous les cas.

[Landry Breuil]

On 11/05/2025 15:19, Florian Necas wrote:
> J'ai créé un ticket par rapport à la réorganisation de la codebase
> georchestra. https://github.com/georchestra/georchestra/issues/4470
>
> J'aime beaucoup l'idée de Julien mais je modifierait en upstream-
> georchestraSpecific+georchestraCore, ce qui donnerai 2024.01.00-01+24.0

tant qu'il n'y a pas d'adhésion/dépendance entre mapstore et une version
spécifique de georchestra (besoin d'une feature précise dans la
gw/analytics, que sais-je), je ne vois aucune raison de mettre le numéro
de version de georchestra dans le mix, ce qui laisserait entendre
'compatible uniquement avec cette version'...

--
Landry Breuil

[Julien Sabatier]

Je ne proposais pas d'inclure la version de geOrchestra, mais une version propre à mapstore2-georchestra (le 1.0.0 dans mon exemple)
La partie derrière le + est la version du projet upstream duquel dépend notre projet.

Je n'ai pas inventé ce versioning, il découle de la norme semver :  https://semver.org/lang/fr/

2024.01.00-01+24.0 : cette notation ne respecte pas semver (l'utilisation du - est réservé pour les pré-livraison) et  me parait mauvaise car elle ne définit aucune version du projet mapstore2-georchestra mais uniquement les versions mapstore et geOrchestra compatibles.

Je pense que le versioning n'a pas vocation à remplacer une matrice de compatibilité et en voulant faire cela, on s'écarte des normes existantes.

Dans la norme semver, la partie après le + correspond aux metadonnées de build, je suggérait la possibilité d'y faire figurer la version de mapstore car ça me parait l'info la plus pertinente à ce niveau.

[François Van Der Biest]

Je suis d'accord avec ce point de vue !

--
--
Vous avez reçu ce message, car vous êtes abonné au groupe
Groupe "georchestra" georc...@googlegroups.com
voir http://groups.google.fr/group/georchestra

Site web : http://www.georchestra.org

---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes georchestra.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse georchestra...@googlegroups.com.
Pour afficher cette discussion, accédez à https://groups.google.com/d/msgid/georchestra/28bfee1f-d94e-4390-b669-c7dc3ef045b6%40craig.fr.

[Florian Necas]

On a  trois numéros de version à maintenir:

- la version de notre l'application.

- la version de l'application upstream (si applicable).

- la version majeure de georchestra compatible.

Le problème de la notation 1.0.0+mapstore.2024.02, c'est qu'elle n'en contient que deux. 
Sinon <app-version>+<upstream-version>--<georchestra-major-version>
Ce qui donnerait (dans le cas ou l'on a beosin d'identifier la version de georchestra): 
- pour mapstore : 1.0.0+2024.02.02--24.0
- pour la gateway (pas d'upstream): 2.0.0+24.0

- pour geonetwork 1.0.1+4.2.8--23.0
https://regex101.com/r/Ly7O1x/3/

Ca peut être un peu lourd mais ça couvre tous les cas ! 

[Florian Necas]

Bon, finalement je suis en faveur des numéros de versions de Julien. 
Si c'est ok comme comportement pour tout le monde, j'acte ça et on peut démarrer la codebase reorganization correctement :)
https://github.com/georchestra/georchestra/issues/4470

| georchestra core | mapstore | gn | gateway |
|------------------|-------------------------------------------------|-------------|---------|
| branch 24.0.x | 1.0.x+2023.02.02 (can contain 1.0.x+2023.02.03) | 1.0.x+4.2.8 | 2.0.x |
| tag 24.0.2 | 1.0.2+2023.02.02 | 1.0.0+4.2.8 | 2.0.0 |
| branch 24.1.x | 1.1.x+2023.02.02 | 2.0.x+4.4.5 | 2.1.x |

Issue github
Ok I missed something on google discussion. I wanted to keep track of 3 versions.

• georchestra's one : 24.0.x
• upstreams's one: 2024.02.xx
• custom's fork patches: -1 ...

But. When core will upgrade. E.g: 24.0 to 24.1 and IF apps need to be updated, there's no need to keep georchestra's version in name but only to bump app version.

Suppose we are in version 1.0.0+2024.02.02 and georchestra's core updates from 24.0 to 25.0. We will create a new branch/tags for our app which will be 1.1.0+2024.02.02 or 2.0.0+2024.02.02

Each app can have custom patches, georchestra's compatibilities, with only The first part of it.

I update my issue and respond on google group too.

[Landry Breuil]

On 20/05/2025 15:39, Florian Necas wrote:
>
> Bon, finalement je suis en faveur des numéros de versions de Julien.
> Si c'est ok comme comportement pour tout le monde, j'acte ça et on peut
> démarrer la codebase reorganization correctement :)

je suis désolé, mais je ne vois toujours pas la raison fondamentale de
compliquer le numéro de version en 'inventant' une partie en plus sortie
de nulle part. je connais semver merci, mais c'est overkill pour les
histoires de cassage d'api de mapstore2 ici...

pour moi, ça n'a pas de sens d'avoir 2 releases ayant un contenu
identique et des numéros de versions différents, que ce soit dans la
même branche de georchestra ou dans des branches distinctes.

on va se retrouver de nouveau a tagger X fois le même commit du repo
ms2-georchestra a chaque sortie d'une version mineure de georchestra ?

ou alors il y'a des besoins implicites liés à de l'infra (docker/k8s)
qui n'ont pas été exprimés clairement et je n'ai pas compris la raison ?

mais je me rangerais a l'avis de la majorité, je n'ai plus d'énergie à
consacrer au sujet.

--
Landry Breuil

[Julien Sabatier]

Je ne pense pas qu'il soit judicieux de vouloir faire figurer 3 versions en 1, ça va juste encore compliquer un versionning déjà complexe à aborder.

L'idée d'utiliser semver me paraissait intéressante, mais dans le but d'apporter de l'information sur la criticité d'une montée de version, ce qui est l'objectif de semver.

Si le besoin est d'informer sur les version du cœur geOrchestra pris en charge et de l'upstream utilisé, alors je pense qu'un tableau dans le README sera plus adapté, comme c'est fait par exemple pour Tomcat : 

https://tomcat.apache.org/whichversion.html => Cas différent mais similaire

Il pourrait être intéressant d'avoir d'éventuels retours au geOcom de la parts de personnes arrivant dans la communauté sur la compréhension des versions et son impact sur le déploiement de leur plateforme.

D'après le message d'origine de ce thread, le but d'un changement de versionning était d'apporter plus de clarté pour les personnes extérieures au projet.

Enfin il est évident que cela ne doit pas rendre plus complexe la publication de nouvelles releases pour ceux qui s'en chargent.