-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Quels principes utiliser concernant les évolutions des composants ? #301
Comments
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. |
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 |
Je pense notamment à :
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 ?
The text was updated successfully, but these errors were encountered: