search

opengisch / OpenComptage

Neuchâtel "comptages"
2 stars 3 forks source link

Quels principes utiliser concernant les évolutions des composants ? #301

Open spch-GL opened 9 months ago

spch-GL commented 9 months ago

Je pense notamment à :

requirements | sortie | actuelle | date -- | -- | -- | -- nose2==0.8.0 | 31.07.2018 | 0.14.0 | 05.10.2023 psycopg2-binary==2.8.6 | 07.09.2020 | 2.9.9 | 03.10.2023 icalendar==4.0.3 | 10.10.2018 | 5.0.11 | 03.11.2023 openpyxl==3.1.2 | 11.03.2023 | 3.1.2 | 11.03.2023 django==3.2.15 | 03.08.2022 | 4.2.7 | 01.11.2023 plotly==5.3.1 | 01.09.2021 | 5.18.0 | 25.10.2023 pandas==1.3.4 | 17.10.2021 | 2.1.3 | 10.11.2023

Concernant QGIS, je proposerais d'utiliser la dernière LTR (sauf lorsqu'un développement demande la dernière release, mais je pense que nous n'en aurons pas besoin) J'ai vu que tu avais déjà mis à jour openpyxl, merci. Je ne sais pas si il y en a, mais si il y a des failles de sécurité comblées ou des performances améliorées, ne serait-il pas judicieux d'envisager les mises à jour ? Quels autres critères envisager ?

why-not-try-calmer commented 9 months ago

En effet, normalement la meilleure chose à faire du point de vue logiciel est de toujours rester près de la dernière version, mais suffisamment "loin" pour avoir des garanties (testées manuellement) de compatibilités entre toutes les dépendances. En clair, pour les paquets Python ça veut dire dans l'idéal jamais plus d'une année de la dernière version. Pour QGIS c'est un peu différent, mais en tout cas ce que tu proposes me semble une bonne chose. La LTR actuelle est la version 3.34.0.

Je peux mettre à jour QGIS et les dépendances dans cette logique-là.

Cela dit, je vais faire cette mise à jour "de masse" à la fin, histoire de ne pas m'emmêler les pinceaux entre des bugs à proprement dit et des problèmes de comptabilités.

spch-GL commented 9 months ago

Petite correction: la LTR actuelle est encore la 3.28.12 et sera probablement en 3.34.4 en février selon la feuille de route

Parfait pour le reste