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 22 and Version 23 of fr/patchs


Ignore:
Timestamp:
May 9, 2012, 12:20:42 AM (7 years ago)
Author:
laurentj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • fr/patchs

    v22 v23  
    4444Si vous fournissez des patchs régulièrement (indépendants ou non), la meilleure façon est de "forker" le dépôt de jelix dans votre compte github.
    4545
    46 Créez une branche dans votre "fork", pour chaque modification distincte (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.
     46'''Créez une branche dans votre "fork", 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.
     47
     48'''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'''.
    4749
    4850Pour 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.