Ajout des photos de montage des étriers de frein #37

There is no content yet.

Top tout ça ! Merci encore pour ces belles photos.

Pour info, on peut voir le résultat ici : https://documentation.vhelio.org/doc/git.vhelio.org!2Fvhelio/vheliotech-guide-de-montage/main/050_montage_pieces_cycles.html#montage-des-etriers-de-frein

Peut-être qu'il faudrait qu'on merge tout ça dans la branche 1.0.0 (ou 1.0.1 ?) un jour pour que la doc officielle intègre les dernieres modifs.
T'en penses quoi @youen ?

Ah mince, par contre, je n'avais pas vu que le rendu PDF des tableaux n'est pas bon... voir : https://documentation.vhelio.org/doc/git.vhelio.org!2Fvhelio/vheliotech-guide-de-montage/main/vheliotech-guide-de-montage.pdf

Je pense que ça vient du fait que tu as mis des balises <img> avec une taille fixe, j'essaie de corriger ça dans la journée.

Pour moi l'idée est que quand on sortira une nouvelle version, on mettra un tag avec le numéro de la version. Il n'y a pas vraiment besoin de créer une branche, sauf si on doit faire des correctifs de dernière minute alors que certaines modifs continuent dans la branche "main" qu'on ne voudrait pas publier tout de suite dans la nouvelle version. Mais pour le moment je pense qu'on peut considérer que tout ce qui est fait dans la branche "main" ira dans la prochaine version, non ?

Dans tous les cas, on ne merge rien dans la branche v1.0.0 (son contenu est arrêté et ne doit plus évoluer).

Dans tous les cas, on ne merge rien dans la branche v1.0.0 (son contenu est arrêté et ne doit plus évoluer).

Justement c'est ça que je me demandais. Vu que les modifications de la documentation portent toutes sur la 1.0.0 (par exemple, ce ne sont pas des nouveaux étrier de freins), est-ce qu'il ne serait pas judicieux de faire pointer la doc officielle sur main ?

Ou alors de backporter certains correctifs dans une branche 1.0.1 ou dans la branche 1.0.0 directement ?

Je ne sais pas si ce que je propose est claire ?

En gros, vu qu'il s'agit de correctifs et d'amélioration de la doc v1.0.0, il me paraitrait judicieux que ces correctifs soient officiellement publiés pour la v1.0.0 non ?

Par exemple, dans le monde logiciel, quand on décorelle la version du logiciel de la documentation. Une documentation pour la v1.0.0 peut être mise à jour après la sortie de la v1.0.0 tu vois ?

En effet, ce sont des apports à la v1.0.0 sur les mêmes composants, tant que ce sont juste des apports de forme, on ne prend pas de risque (à part le PDF, bien vu, je regarderai tes correctifs @AndreasL).

Je n'ai pas encore d'expérience avec les tags, donc je laisse @youen nous guider.

Hmm, non, honnêtement, je ne vois pas trop. La v1.0.0 est terminée. La prochaine version sera peut-être v1.0.1, ou peut-être v1.1.0, ou peut-être v2.0.0, à ce stade on ne sait pas. Et cette future version prendra tout ce qui a été fait (au moins jusqu'à présent) dans "main". Tant qu'on n'a pas deux versions différentes en développement simultanément, je ne vois pas l'intérêt de faire une branche ? Si cela se produit un jour, il ne sera jamais trop tard pour créer une branche...

On pourrait même supprimer la branche 1.0.0 (et ne garder que le tag). Mais pour moi c'est bien la branche "main" qui contient le travail en cours pour la prochaine version, comme c'est le cas actuellement, et je ne vois pas de raison de faire plus compliqué que ça ?

Si ta question porte sur la fréquence de publication de nouvelles versions, alors il faut voir ça avec le CA ;-) Je trouve qu'actuellement il y a énormément d'inertie. Des problèmes identifiés sont corrigés mais pas validés pour publication (même si le travail en cours est accessible à tout le monde). En tout cas je ne pense pas que créer ou merger des branches aiderait sur ce point.

Quelques précisions qui me passent par la tête :

La branche version_1.0.0 actuelle désigne bien une version spécifique. Ce n'est pas la branche de la v1.x.x ni même v1.0.x ; je l'avais créée uniquement pour pouvoir mettre les metadata de cette version dans les fichiers utilisés lors de la compilation (qui au final s'affiche sur le site web documention.vhelio.org), cf fichier current_version_data.py qui est différent de celui de la branche "main" ou "version_0.01".
Si on publiait une nouvelle version maintenant, on l'appellerait sans doute v1.0.1, je crois qu'on est tous d'accord là dessus. Il s'agit de précisions et corrections dans la doc, sans changements de fond. Je ne pense pas que ce soit incompatible avec l'existence d'une seule branche "main" dans laquelle on fait le travail au fur et à mesure.
Je pense qu'il faudra autant que possible éviter de gérer plusieurs versions simultanément. Par exemple aujourd'hui on ne va pas backporter de correctifs dans la version 0.01, ça n'aurait pas de sens, elle est totalement supplantée par la 1.0.0. Ce serait du travail en plus, mais sans intérêt pour la communauté. Rien n'indique aujourd'hui qu'on ne pourra pas continuer de la même façon indéfiniment (si on sort une v1.1.0, il n'y aura probablement aucun intérêt à faire des correctifs dans la v1.0.0, etc.) ; mais si toutefois le cas se présentait alors on pourra aviser le moment venu.
Le numérotage des versions est actuellement décidé par le CA, ainsi que la validation d'une version pour la déclarer "prête à utiliser". Ce numérotage concerne l'ensemble de la documentation (guide de montage, nomenclature, notice d'utilisation, fichiers 3D, etc.). On ne peut donc pas trop décider, au niveau du seul guide de montage, de créer une branche avec un nouveau numéro de version. C'est un peu bête, mais il y a actuellement du travail rien que pour incrémenter le numéro de version dans tous les documents, et les publier sur le forum.
Fusionner des branches, ou backporter des choses, sera probablement assez facile pour le guide de montage, mais nettement plus complexe (et source d'erreurs) pour tout le reste. Donc ne nous enflammons pas trop sur cette idée ;-)

Quelques précisions qui me passent par la tête : * La branche version_1.0.0 actuelle désigne bien une version spécifique. Ce n'est pas la branche de la v1.x.x ni même v1.0.x ; je l'avais créée uniquement pour pouvoir mettre les metadata de cette version dans les fichiers utilisés lors de la compilation (qui au final s'affiche sur le site web documention.vhelio.org), cf fichier current_version_data.py qui est différent de celui de la branche "main" ou "version_0.01". * Si on publiait une nouvelle version maintenant, on l'appellerait sans doute v1.0.1, je crois qu'on est tous d'accord là dessus. Il s'agit de précisions et corrections dans la doc, sans changements de fond. Je ne pense pas que ce soit incompatible avec l'existence d'une seule branche "main" dans laquelle on fait le travail au fur et à mesure. * Je pense qu'il faudra autant que possible éviter de gérer plusieurs versions simultanément. Par exemple aujourd'hui on ne va pas backporter de correctifs dans la version 0.01, ça n'aurait pas de sens, elle est totalement supplantée par la 1.0.0. Ce serait du travail en plus, mais sans intérêt pour la communauté. Rien n'indique aujourd'hui qu'on ne pourra pas continuer de la même façon indéfiniment (si on sort une v1.1.0, il n'y aura probablement aucun intérêt à faire des correctifs dans la v1.0.0, etc.) ; mais si toutefois le cas se présentait alors on pourra aviser le moment venu. * Le numérotage des versions est actuellement décidé par le CA, ainsi que la validation d'une version pour la déclarer "prête à utiliser". Ce numérotage concerne l'ensemble de la documentation (guide de montage, nomenclature, notice d'utilisation, fichiers 3D, etc.). On ne peut donc pas trop décider, au niveau du seul guide de montage, de créer une branche avec un nouveau numéro de version. C'est un peu bête, mais il y a actuellement du travail rien que pour incrémenter le numéro de version dans tous les documents, et les publier sur le forum. * Fusionner des branches, ou backporter des choses, sera probablement assez facile pour le guide de montage, mais nettement plus complexe (et source d'erreurs) pour tout le reste. Donc ne nous enflammons pas trop sur cette idée ;-)

Visiblement c'est pas simple la mise en page de tableau avec des images dedans.
J'ai pas encore trouvé une solution satisfaisante pour le mode html et pour le mode pdf en même temps.

Je continue de chercher, je vous dis après.

Pour te répondre @youen, je pense qu'on est a peu près d'accord, ça me va de publier une 1.0.1 à un moment.

En revanche, si on se met à faire des modifs dans la 3D (en vu d'une v1.1 ou une v2.0), là il faudra bien différencier les modifs correctives (exemple cette PR) des modifs qui apportent de réels changements au vhélio. C'est en ça que je disais qu'à un moment on aura sans doute besoin de faire plusieurs branches.

Oui, OK, effectivement, je n'exclue pas la possibilité qu'à un moment on puisse avoir besoin de développer une nouvelle version tout en maintenant l'ancienne. Mais si on en a la possibilité, ce serait nettement plus pratique et productif de ne pas faire de maintenance sur les anciennes versions (et ça me semble possible car les nouveaux vhélios se feront avec les nouvelles pièces, alors que les anciens n'auront pas besoin d'amélioration de la doc pour le reste de leur durée de vie s'ils sont déjà assemblés). Bref, le cas échéant, on verra le moment venu...