release ext-ol-3.0.15

DRAFT_CHANGELOG.md

@@ -6,22 +6,40 @@
 
 ## Summary
 
+* gestion des loggers : 
+> Exposition de la classe statique *Logger* avec les méthodes suivantes :
+`Gp.Logger.disableAll()` et `Gp.Logger.enableAll()`
+* correctif sur le profil altimétrique
+
 ## Changelog
 
 * [Added]
 
 * [Changed]
 
-    - mise à jour de la jsDoc (95cff8206ef2e0fcfb7fee5989d2d74d236b9f9f)
+    - mise à jour de la jsDoc (95cff82)
+    - mise à jour de la lib. geoportal-access-lib : 2.1.8
 
 * [Deprecated]
 
 * [Removed]
 
+    - la dépendance *request* est supprimée, et remplacée par *node-fetch* (#295)
+
 * [Fixed]
 
+    - Possibilité de activer / desactiver les loggers des API lors de l'utilisation des API en module ES6 :
+
+    ```js
+    import { Logger } from "geoportal-extensions-openlayers";
+    Logger.disableAll();
+    ```
+
     - corrections des erreurs à partir de DeepScan (#288)
-    - corrections syntaxiques eslint (da275a284a07ddd8e32753eda57ad4ef283d34fb et 306506a2255b2f05558ddcb05210dce39135c804)
+    - corrections syntaxiques eslint (da275a2 et 306506a)
+    - cf. issue : Erreur compilation par webpack [#294](https://github.com/IGNF/geoportal-extensions/issues/294)
+    - cf. issue : Erreur dépendances à la compilation [#283](https://github.com/IGNF/geoportal-extensions/issues/283)
+    - fix profil altimetrique amCharts + D3 (#296)
 
 * [Security]
 
@@ -35,52 +53,73 @@
 
 ## Summary
 
+* gestion des loggers : 
+> Exposition de la classe statique *Logger* avec les méthodes suivantes :
+`Gp.Logger.disableAll()` et `Gp.Logger.enableAll()`
+
 ## Changelog
 
 * [Added]
 
 * [Changed]
 
+    - mise à jour de la lib. geoportal-access-lib : 2.1.8
+
 * [Deprecated]
 
 * [Removed]
 
+    - la dépendance *request* est supprimée, et remplacée par *node-fetch*
+
 * [Fixed]
 
+    - Possibilité de activer / desactiver les loggers des API lors de l'utilisation des API en module ES6 :
+
+    ```js
+    import { Logger } from "geoportal-extensions-leaflet";
+    Logger.disableAll();
+    ```
+    
     - corrections des erreurs à partir de DeepScan (#288)
-    - corrections syntaxiques eslint (da275a284a07ddd8e32753eda57ad4ef283d34fb et 306506a2255b2f05558ddcb05210dce39135c804)
+    - corrections syntaxiques eslint (da275a2 et 306506a)
+    - cf. issue : Erreur compilation par webpack [#294](https://github.com/IGNF/geoportal-extensions/issues/294)
+    - cf. issue : Erreur dépendances à la compilation [#283](https://github.com/IGNF/geoportal-extensions/issues/283)
 
 * [Security]
 
 ---
 
 
 
+
 # Extension Geoportail Itowns, version __VERSION__
 
 **__DATE__**
 > Release Extension Geoportail itowns
 
 ## Summary
 
+* gestion des loggers : 
+> Exposition de la classe statique *Logger* avec les méthodes suivantes :
+`Gp.Logger.disableAll()` et `Gp.Logger.enableAll()`
+
 ## Changelog
 
 * [Added]
 
 * [Changed]
 
-    - mise à jour d'iTowns en version 2.30 (#292)
-
 * [Deprecated]
 
 * [Removed]
 
 * [Fixed]
 
-    - corrections des erreurs à partir de DeepScan (#288)
-    - corrections syntaxiques eslint (da275a284a07ddd8e32753eda57ad4ef283d34fb et 306506a2255b2f05558ddcb05210dce39135c804)
-    - correction de la synchronisation des couches vecteur tuilé avec leurs labels (#290)
+    - Possibilité de activer / desactiver les loggers des API lors de l'utilisation des API en module ES6 :
 
+    ```js
+    import { Logger } from "geoportal-extensions-itowns";
+    Logger.disableAll();
 
 * [Security]
 

TEAM_DEV_WORKFLOW.md

@@ -1,8 +1,8 @@
 # Workflow git pour les APIs web
 
-Description du workflow de travail git pour les APIs.
+Description du workflow de travail git pour les APIs. ([Workflow pour le composant portail-visu](https://gitlab.ul.geoportail.rie.gouv.fr/ign/pgie/portail-visucarto/wikis/Workflow-:-tests-et-livraisons-de-portail-visucarto))
 
-Ce workflow se base sur git-flow, un "template" de workflow, qui peut notamment fonctionner avec des plugins git à installer. 
+Ce workflow se base sur git-flow, un "template" de workflow, qui peut notamment fonctionner avec des plugins git à installer.
 
 Dans un premier temps, nous essayerons de nous passer de ces plugins qui impliqueraient que tout le monde les installe, et de nouvelles signatures de commandes git.
 
@@ -44,6 +44,31 @@ Nous nous retrouvons donc avec 5 types de branches distinctes.
 
 Voir : https://buzut.net/git-bien-nommer-ses-commits/
 
+
+Joints à cette page du wiki (retirer le .txt si possible), les templates de commits pour chaque projet :
+- .git-commit-template-accesslib
+- .git-commit-template-extensions
+- .git-commit-template-sdk
+
+Pour les installer, les déposer sur sa machine (exemple : à la racine)
+
+
+1 - Se placer à la racine du projet voulu (accesslib, extensions, sdk)
+
+
+2 - Configurer le git projet pour utiliser le template voulu lors des commits
+~~~
+git config commit.template ~/.git-commit-template-accesslib
+~~~
+ou
+~~~
+git config commit.template ~/.git-commit-template-extensions
+~~~
+ou
+~~~
+git config commit.template ~/.git-commit-template-sdk
+~~~
+
 **Explication du template des commits :**
 
 ~~~ text
@@ -56,19 +81,30 @@ Voir : https://buzut.net/git-bien-nommer-ses-commits/
 ~~~
 
 
+
+
 **Les TYPES** :
 
 Ils sont détaillés dans le lien (build, fix, feat, refactor...)
 
 
 **Le SCOPE :**
 
-*Facultatif* - 
+*Facultatif* - Il va dépendre du projet, et est facultatif, car n'est pas forcément pertinent :
+
+*Projet access-lib :*
+- Exeptions
+- Formats
+- Protocols
+- Services
+- Utils
+- Samples
+- ...
 
 *Projet extensions :*
 - common:CSS
 - common:DOM
-- common:Utils 
+- common:Utils
 - ol:Controls
 - ol:CRS
 - ol:CSS
@@ -88,6 +124,29 @@ Ils sont détaillés dans le lien (build, fix, feat, refactor...)
 - it:Samples
 - ...
 
+*Projet SDK :*
+- 2D:Interface
+- 2D:Base
+- 2D:Controls
+- 2D:Layers
+- 2D:Listeners
+- 2D:VectorTiles
+- 2D:View
+- 2D:Utils
+- 2D:CSS
+- 2D:Samples
+- 3D:Interface
+- 3D:Base
+- 3D:Controls
+- 3D:Layers
+- 3D:Listeners
+- 3D:VectorTiles
+- 3D:View
+- 3D:Utils
+- 3D:CSS
+- 3D:Samples
+- ...
+
 **Le SUJET :**
 
 Se limiter à 50 caractères pour donner une idée claire de l'objectif du commit, avec une forme active. Compléter si besoin dans la description.
@@ -101,7 +160,15 @@ Se limiter à 50 caractères pour donner une idée claire de l'objectif du commi
 *Facultatif* - Sauter une ligne entre le footer et le bloc précédent. Permet de linker un ticket par exemple, pour un commit correctif.
 
 
-**EXEMPLE**
+**EXEMPLES**
+
+Un commit qui corrige le ticket 32223 sur l'ajout d'un paramètre facultatif lors de l'ajout d'une couche dans le SDK2D :
+
+~~~ text
+fix(2D:Layers): Ajoute le paramètre xxx lors de l'ajout d'une couche WMTS
+
+#32223
+~~~
 
 Un commit qui ajoute des systèmes de coordonnées au mousePosition openlayers :
 
@@ -131,15 +198,17 @@ git checkout develop
 git checkout -b feature-MYFEATURE
 ~~~
 
-2 - Je travaille sur ma branche 
+2 - Je travaille sur ma branche
 
 3 - Je rapatrie develop sur ma branche feature
 
-4 - J'ai fini : J'ouvre une PR depuis develop sur ma branche feature-MYFEATURE 
+4 - J'ai fini : J'ouvre une PR depuis develop sur ma branche feature-MYFEATURE
+
+5 - Je fais les eventuelles corrections soulevées par la review de PR sur ma branche
 
-5 - Je fais les eventuelles correstions soulevées par la review de PR sur ma branche
+6 - Je tiens à jour le DRAFT_CHANGELOG.md
 
-6 - Tout est OK : je valide la PR et rapatrie donc ma branche feature sur develop
+7 - Tout est OK : je valide la PR et rapatrie donc ma branche feature sur develop
 
 ## Bug Fix et Refacto
 
@@ -149,59 +218,75 @@ Les "gros" bug fixes ou refacto sont à considérer comme des features: c'est à
 
 ## Release
 
-0 - Sur develop, modifier le package.json pour incrémenter numéro de version et date
-
 1 - Tirer une branche de type **"release"** à partir de **develop**
 
 ~~~
 git checkout develop
 git checkout -b release-X.Y.Z
+git push origin release-X.Y.Z
 ~~~
 
-2 - Réaliser sur cette branche release les tests habituels liés à la publication d'une release
+2 - Sur cette branche, modifier le package.json pour incrémenter numéro de version et la date
+
+3 - Réaliser sur cette branche release les tests habituels liés à la publication d'une release (npm run test, npm run sample:serve)
 
-3 - Si on trouve des bugs, on les corrige directement sur cette branche release (plusieurs membres de l'équipe peuvent réaliser les verifications/corrections en parrallèle sur la branche release)
+4 - Si on trouve des bugs, on les corrige directement sur cette branche release (plusieurs membres de l'équipe peuvent réaliser les verifications/corrections en parrallèle sur la branche release)
 
 ~~~
 git commit --> "fix(scope) : corrige le probleme"
 ~~~
 
-4 - On rapatrie ce fix sur develop
+5 - On rapatrie ce fix sur develop
 
 ~~~
 git checkout develop
 git merge release-X.Y.Z
 ~~~
 
-5 - On recommence autant de fois que necessaire les etapes 3 et 4
+6 - On recommence autant de fois que necessaire les etapes 4 et 5
 
-6 - Quand on estime que tout est ok, on prépare la future publication npm en construisant les binaires :
-* cd build/script/release
+7 - Quand on estime que tout est ok, on prépare la future publication npm en construisant les binaires :
 * vérifier date et version dans les package.json
-* ./build-pack.sh
-* commiter
+* vérifier que le DRAFT_CHANGELOG est à jour
+* pousser la branch
 
-6 - Quand on estime que la release est OK, on merge la branche sans fast-forward sur **develop**
+8 - Quand on estime que la release est OK, on merge la branche sans fast-forward sur **develop**
 
 ~~~
 git checkout develop
 git merge release-X.Y.Z --no-ff
 ~~~
 
-6 - Quand on estime que la release est OK, on merge la branche sans fast-forward sur **master** et on tag la version sur master
+9 - Quand on estime que la release est OK, on merge la branche sans fast-forward sur **master** et on tag la version sur master
 
 ~~~
 git checkout master
 git merge release-X.Y.Z --no-ff
 ~~~
 
-7 - On supprime la branche release ainsi mergée
+**Renommer le commit "release sdk-X.Y.Z" ou "release ext-ol-X.Y.Z"**
+
+10 - On supprime la branche release ainsi mergée
 
 ~~~
 git branch -d release-X.Y.Z
 ~~~
 
-8 - Sur master, on réalise les étapes habituelles de **publication de la jsdoc et de la release**
+11 - Sur master, on tag  la version. Pousser le tag va déclencher automatiquement les étapes de **publication de la jsdoc et de la release npm/github** via les githubs actions
+
+~~~
+git tag ol-X.Y.Z
+git push origin ol-X.Y.Z
+~~~
+
+12 - Vérification de la publication :
+* suivre en direct via les githubs actions
+* vérifier page de publication de la release github
+* vérifier page de publication de la release npm
+* vérifier que la jsdoc (gh-pages) est à jour
+* vérifier que le projet exemples a été mis à jour avec la nouvelle release (par ex. https://github.com/IGNF/geoportal-access-lib-samples)
+* vérifier que le DRAFT_CHANGELOG a été vidé et que le CHANGELOG a été mis à jour
+
 
 ## Realisation d'un hotfix
 
@@ -211,6 +296,7 @@ Dans quel cas : Je remarque un problème à corriger de toute urgence sur la der
 ~~~
 
 git checkout -b hotfix-MYHOTFIX master
+git push origin hotfix-MYHOTFIX
 ~~~
 
 2 - Sur cette branche hotfix-MYHOTFIX, j'incrémente la version de la release package.json
@@ -234,12 +320,19 @@ git merge hotfix-MYHOTFIX --no-ff
 git checkout master
 git merge hotfix-MYHOTFIX --no-ff
 git tag X.Y.Z
+git push origin X.Y.Z
 ~~~
 
-6 - On supprime la branche hotfix mergée
+6 - Vérification de la publication lancée par le tag sur master :
+* suivre en direct via les githubs actions
+* vérifier page de publication de la release github
+* vérifier page de publication de la release npm
+* vérifier que la jsdoc (gh-pages) est à jour
+* vérifier que le projet exemples a été mis à jour avec la nouvelle release (par ex. https://github.com/IGNF/geoportal-access-lib-samples)
+* vérifier que le DRAFT_CHANGELOG a été vidé et que le CHANGELOG a été mis à jour
+
+7 - On supprime la branche hotfix mergée
 
 ~~~
 git branch -d hotfix-MYHOTFIX
 ~~~
-
-7 - Sur master, on réalise les étapes habituelles de **publication de la jsdoc et de la release**