Accéder et participer au code de Yacs
Yacs est maintenant disponible sur la plateforme collaborative github où L'intégralité du code est géré.
Le choix a été fait de basculer sur une gestion du code avec Git pour ses qualités et ses fonctionnalités permettant une intégration plus rapide des différentes contributions.
Le principe adopté est d'avoir trois branches différentes et autant de branches "personnelles" que de contributions.
En effet, avec Git, chacun se construit son propre fork sur la base de la branche à laquelle il contribue. On admet par souci d'efficacité, qu'on construit une branche pour un travail sur une fonctionnalité. Il peut donc y avoir plusieurs branches par contributeur, basées sur des branches yacs différentes si besoin.
Voici en synthèse ce que ça donne : * [b]Master[/b] : c'est la branche de référence. Elle contient du [i]code testé mais [b]pas[/b] estampillé stable[/i]. C'est une version "buildée", qui convient pour ceux qui savent ce qu'ils font, ou qui n'engagent qu'eux-mêmes en l'utilisant en production.
version "buildée" veut dire que l'archive mise en dépôt a été construite selon une procédure propre à yacs qui garantit le bon fonctionnement de la mise à jour d'un serveur avec l'archive. Principalement cela veut dire footprint.php valide, les bons fichiers de langues, et les scripts run_once à jour. * [b]Stable[/b] : c'est la branche correspondant à [b]la dernière version majeure[/b]. Seules des corrections de bugs y sont injectées. C'est aussi une version "buildée", [b]recommandé pour les serveurs de production[/b]. * [b]Next[/b] : c'est la branche "alpha", dans laquelle est injecté le code des topic-branches émanent des contributeurs, après revue de code. Elle permet de tester les nouvelles contributions rassemblées. * Les [b]topic-branches[/b] : elles ne sont généralement pas dans le dépôt yacs/yacs, mais sont des branches contenant UNE fonctionnalité, situées [i]dans les dépôts des contributeurs[/i], et desquelles émanent les pull-request (demandes d'ajout au code consolidé). Le code des topic-branches est revu par les intégrateurs avant d'être fusionné dans la branche next.
[title]Ressources[/title] * Le groupe de travail sur le code source de Yacs : Il rassemble toutes les discussions, les tutos, les synthèses. C'est la section de référence pour tout contributeur. C'est en anglais
, et c'est ici, sur yacs.fr. N'hésitez pas à mettre cette section dans votre liste de surveillance pour être avertit de toute nouveauté.
* Plus directement, une introduction (assez détaillée) au workflow de contribution au code de Yacs avec Git : à lire si vous souhaitez avoir un aperçu de "comment ça fonctionne".
* Pour accéder au dépôt de Yacs sur Github
* Pour récupérer le code source : pour ceux qui souhaitent récupérer des versions qui ne sont pas encore en téléchargement sur notre site. Elles sont spécifiquement construites pour être opérationnelles (version buildées) - sauf si vous arrivez dans une période de transition, ce qui n'est pas si courant. À réserver à ceux qui savent ce qu'il font, bien sûr.
* Nous avons eu une soirée clavardage dédiée au passage de svn à Git. Vous pouvez lire les échanges ici.
Le principe adopté est d'avoir trois branches différentes et autant de branches "personnelles" que de contributions.
En effet, avec Git, chacun se construit son propre fork sur la base de la branche à laquelle il contribue. On admet par souci d'efficacité, qu'on construit une branche pour un travail sur une fonctionnalité. Il peut donc y avoir plusieurs branches par contributeur, basées sur des branches yacs différentes si besoin.
Voici en synthèse ce que ça donne : * [b]Master[/b] : c'est la branche de référence. Elle contient du [i]code testé mais [b]pas[/b] estampillé stable[/i]. C'est une version "buildée", qui convient pour ceux qui savent ce qu'ils font, ou qui n'engagent qu'eux-mêmes en l'utilisant en production.
version "buildée" veut dire que l'archive mise en dépôt a été construite selon une procédure propre à yacs qui garantit le bon fonctionnement de la mise à jour d'un serveur avec l'archive. Principalement cela veut dire footprint.php valide, les bons fichiers de langues, et les scripts run_once à jour. * [b]Stable[/b] : c'est la branche correspondant à [b]la dernière version majeure[/b]. Seules des corrections de bugs y sont injectées. C'est aussi une version "buildée", [b]recommandé pour les serveurs de production[/b]. * [b]Next[/b] : c'est la branche "alpha", dans laquelle est injecté le code des topic-branches émanent des contributeurs, après revue de code. Elle permet de tester les nouvelles contributions rassemblées. * Les [b]topic-branches[/b] : elles ne sont généralement pas dans le dépôt yacs/yacs, mais sont des branches contenant UNE fonctionnalité, situées [i]dans les dépôts des contributeurs[/i], et desquelles émanent les pull-request (demandes d'ajout au code consolidé). Le code des topic-branches est revu par les intégrateurs avant d'être fusionné dans la branche next.
[title]Ressources[/title] * Le groupe de travail sur le code source de Yacs : Il rassemble toutes les discussions, les tutos, les synthèses. C'est la section de référence pour tout contributeur. C'est en anglais
, et c'est ici, sur yacs.fr. N'hésitez pas à mettre cette section dans votre liste de surveillance pour être avertit de toute nouveauté.
* Plus directement, une introduction (assez détaillée) au workflow de contribution au code de Yacs avec Git : à lire si vous souhaitez avoir un aperçu de "comment ça fonctionne".
* Pour accéder au dépôt de Yacs sur Github
* Pour récupérer le code source : pour ceux qui souhaitent récupérer des versions qui ne sont pas encore en téléchargement sur notre site. Elles sont spécifiquement construites pour être opérationnelles (version buildées) - sauf si vous arrivez dans une période de transition, ce qui n'est pas si courant. À réserver à ceux qui savent ce qu'il font, bien sûr.
* Nous avons eu une soirée clavardage dédiée au passage de svn à Git. Vous pouvez lire les échanges ici.