Versionnement d'Archipelago
mguihal opened this issue · 7 comments
Tension
N/A
Proposition
Actuellement, Archipelago n'est pas versionné, et ne possède pas de changelog. Or visiblement il y a plusieurs projets qui l'utilisent un peu partout et ça rend plus difficile de :
- Détecter les impacts des changements entre deux commits
- Pouvoir rester fixé à une version donnée si on ne souhaite pas intégrer les dernières évolutions
Je propose d'utiliser Semver, et de régulièrement créer de nouvelles releases/tags en y intégrant un changelog des derniers commits
Alternatives
N/A
Cela me semble être une bonne idée aussi !
Je propose de mettre le changelog directement dans la release Github car, pour avoir créé un changelog pour le projet SemApps, c'est lourd à maintenir, notamment parce qu'on ne peut pas mettre des liens facilement vers les commits et les PRs.
@srosset81 et @mguihal j'up cette issue.
Pour le moment nous versionnons nos container archipelago sur Data Players pour garantir la maintenabilité. Pour pouvoir garantire cette maintenabilité à chaque rebuild tout en se basasn sur ce repo git (ne pas changer de code entre les rebuild) il nous faudrait un branche pour chaque release. Je propose donc que un branche et une release soit créé par celles et ceux qui en ont besoin lors de l'ajout d'une fonctionnalité qui doit être mis en prod par exemple.
Ca vous convendrait?
Effectivement, avec la migration vers react-admin 4 qui va arriver d'ici quelques jours, ça va casser des intégrations si on ne versionne pas ce repository :)
Plutôt qu'une branche, un tag ferait totalement l'affaire. Il est possible de faire un git checkout 1.0.0 par exemple si un tag 1.0.0 existe. Est-ce que ça t'irait @simonLouvet ? Ca serait la solution la plus simple, sachant qu'on peut créer un tag en même temps qu'une release dans Github.
La question que je me pose, c'est plutôt comment démarrer le versionnement ? Considère-t'on que la version actuelle serait une 1.0.0, et que la prochaine mise-à-jour de react-admin (ou le prochain breaking) serait une 2.0.0 ? Ou sinon on commence en 0.1.0 ? Puis 0.2.0 ? (comme fait semapps actuellement) Le souci que je vois avec cette deuxième possibilité c'est qu'en s'interdisant d'utiliser le premier chiffre de semver, on ne distingue plus les évolutions major (=breaking change) des minor (=ajout de fonctionnalité sans impact sur l'existant), obligeant de lire le changelog à chaque mise à jour...
Ok pour utiliser les tag et pas les branches. Je propose de considérer que nous somme en 0.1.0 actuellement et la le pasage en react-admin 4 soit le passage en 0.2.0.
ok @mguihal et @srosset81
Je pense que Archipelago est suffisamment mature pour qu'on envisage de passer en 1.0.0 lorsque le passage à React-Admin v4 sera validé. C'est vrai que c'est plus difficile de distinguer les BC lorsqu'on fonctionne en 0.x.0. Pour SemApps ça a été mieux comme ça mais pour Archipelago je n'en vois pas la nécessité.
C'est bon, première release publiée: https://github.com/assemblee-virtuelle/archipelago/releases/tag/v1.0.0