developer.jelix.org is not used any more and exists only for history. Post new tickets on the Github account.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Changes between Version 27 and Version 28 of fr/patchs


Ignore:
Timestamp:
Nov 24, 2015, 9:24:19 PM (5 years ago)
Author:
laurentj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • fr/patchs

    v27 v28  
    33Le code de Jelix est hébergé sur le site Github, qui permet d'apporter des modifications directement en ligne. N'utilisez cette fonctionnalité que pour les modifications très mineures, comme des erreurs d'orthographe, de syntax, bref, pour les modifications qui ne touchent que quelques lignes et un unique fichier. Pour les modifications plus importantes ou qui touchent plusieurs fichiers à la fois, veuillez suivre la procédure suivante.
    44
    5 Pour proposer une modification, vous devez suivre les mêmes étapes que celles du développement de Jelix, [wiki:fr/sources expliquée ici] :
     5Pour proposer une modification, vous devez
    66
    7  1. récupération de la dernière version de jelix '''dans le dépôt git''' et '''non pas''' les fichiers disponibles en téléchargement
    8  1. création d'un fichier de paramètres pour le générateur
    9  1. modification des fichiers sources de jelix (correction de bug, amélioration, nouvelle fonctionnalité etc..)
    10  1. lancement du générateur de sources finales. On obtient un "build"
    11  1. test du build avec une application, en l'occurrence testapp et [wiki:fr/tests ses tests unitaires]
    12  1. si le test est ok, on fait un patch, sinon on recommence à l'étape 2.
    13 
    14 Vous avez vu [wiki:fr/sources toutes les étapes 1 à 5] précédemment. Maintenant voyons pour le patch.
     7 1. récupérer la dernière version de jelix '''dans le dépôt git''' et '''non pas''' les fichiers disponibles en téléchargement.
     8 1. modifier des fichiers sources de jelix (correction de bug, amélioration, nouvelle fonctionnalité etc..)
     9 1. lancer les tests avec vagrant
     10 1. créer le patch si tout est ok.
    1511
    1612== ce que doit contenir votre patch ==
     
    3430'''Créez une branche dans votre clone, pour chaque modifications distinctes''' (pour chaque ticket en gros). Cela permettra alors de fusionner les branches qui ont été acceptées sans inclure vos modifications non terminées ou refusées.
    3531
    36 '''Important''': Vos changements doivent s'effectuer sur les bonnes branches. Vous ne proposerez des modifications dans les branches des versions stables (jelix-1.2.x, jelix-1.3.x), '''que celles qui sont des corrections de bugs'''. Pas d'amélioration ou de fonctionnalités qui changent un comportement, qui peuvent provoquer des régressions etc. Les petites améliorations qui ne font qu'ajouter un plugin ou une méthode sont susceptibles toutefois d'être acceptés.  Rappelez-vous, ce sont des branches '''stables'''. On doit pouvoir mettre à jour Jelix sans avoir à toucher à l'application (sauf si bien sûr, il y a une correction d'un trou de sécurité qui impose de le faire).  Bref, '''toutes les nouveautés doivent être faites dans la branche master'''.
     32'''Important''': Vos changements doivent s'effectuer sur les bonnes branches. Vous ne proposerez des modifications dans les branches des versions stables (jelix-1.5.x, jelix-1.6.x), '''que celles qui sont des corrections de bugs'''. Pas d'amélioration ou de fonctionnalités qui changent un comportement, qui peuvent provoquer des régressions etc. Les petites améliorations qui ne font qu'ajouter un plugin ou une méthode sont susceptibles toutefois d'être acceptés.  Rappelez-vous, ce sont des branches '''stables'''. On doit pouvoir mettre à jour Jelix sans avoir à toucher à l'application (sauf si bien sûr, il y a une correction d'un trou de sécurité qui impose de le faire).  Bref, '''toutes les nouveautés doivent être faites dans la branche master'''.
    3733
    3834Pour les petites modifications, essayez de limiter le nombre de commit. La review sera plus simple et cela permettra de garder un historique clair. Pour les modifications plus conséquentes, il est préférable bien sûr d'avoir plusieurs commits, un pour chaque étape. Afin d'obtenir un historique compréhensible, essayer de faire des commits clairs. Chaque changement devrait correspondre à une étape spécifique de modifications.