mg/qmk_sweep_skeletyl
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
qmk_sweep_skeletyl/docs/fr-fr/breaking_changes.md
Xavier Hahn bed98091aa French translation - FAQ section (#6995) 
* Translated faq.md and added all other files (copy from English)

* Translated driver_installation_zadig.md in French

* Translated faq_build.md in French

* Translated faq_debug in French

* Translateed faq_general.md in French

* Translated first part of faq_keymap.md

* Renamed docs/fr-FR folder to docs/fr-fr

* Finished translation of faq_keymap.md

* Update faq_build.md

* Review (#3)

* Review

* Update docs/fr-fr/faq_keymap.md

* Update docs/fr-fr/faq_debug.md

* Fix some PR comments

Co-Authored-By: Noan Mousy <4sstylz@protonmail.ch>
Co-Authored-By: Wermeille Bastien <bastien.wermeille@gmail.com>
2019-11-03 08:02:44 -08:00

4.1 KiB
Raw Blame History

Breaking changes

Ce document décrit le processus de QMK pour la gestion des breaking changes. Un breaking change est un changement qui modifie la manière dont QMK fonctionne introduisant des incompatibilités ou des comportements dangereux. Nous limitons ces changements afin que les utilisateurs n'aient pas peur de casser leurs keymaps en mettant à jour leur version de QMK.

La période de breaking change est quand nous allons fusionner un PR qui change QMK d'une manière dangereuse ou inattendue. Il y a une période interne de test afin de nous assurer que les problèmes résiduels sont rares ou impossible à prévoir.

Qu'est-ce qui a été inclus dans des Breaking Changes précédents?

Quand va être le prochain Breaking Change?

Le prochain Breaking Change est planifié pour le 29 novembre.

Dates importantes

  • 21 septembre 2019 - future est créé. Il va être rebasé de manière hebdomadaire.
  • 01 novembre 2019 - future fermé aux nouveaux PRs.
  • 01 novembre 2019 - Appel aux testeurs.
  • 27 novembre 2019 - master est bloqué, pas de PRs fusionnés.
  • 29 novembre 2019 - future est fusionné dans master.
  • 30 novembre 2019 - master est débloqué. Les PRs peuvent à nouveau être fusionnés.

Quels changements seront inclus?

Pour voir une liste de candidats de breaking changes, vous pouvez regarder la liste des labels breaking_change. De nouveaux changements peuvent être ajoutés entre maintenant et lorsque future est fermée, et un PR avec ce label n'est pas garanti d'être fusionné.

Si vous souhaitez que votre breaking change soit inclus dans ce tour, vous devez créer un PR avec le label breaking_change et faire en sorte qu'il soit accepté avant que future ne soit fermé. Une fois future fermé, aucun nouveau breaking change sera accepté.

Critère d'acceptation:

  • Le PR est complété et prêt à fusionner
  • Le PR a un ChangeLog

Checklists

Cette section documente plusieurs processus que nous utilisons en lançant le processus de Breaking Change.

Rebase future de master

Ceci est lancé chaque vendredi tant que future est ouvert.

Processus:

cd qmk_firmware
git checkout master
git pull --ff-only
git checkout future
git rebase master
git push --force

Créer la branche future

Ceci est fait immédiatement après la fusion de la branche future précédente.

  • qmk_firmware git commands
    • git checkout master
    • git pull --ff-only
    • git checkout -b future
    • Modifie readme.md
      • Ajoute un message en haut qui indique que c'est une branche de test.
      • Ajoute un lien vers ce document
    • git commit -m 'Branch point for <DATE> Breaking Change'
    • git tag breakpoint_<YYYY>_<MM>_<DD>
    • git tag <next_version> # Evite que le label point d'arrêt soit confondu par un incrément de version
    • git push origin future
    • git push --tags

4 Semaines Avant la Fusion

  • future est maintenant fermé aux nouveaux PRs, seul des correctifs pour les PRs courants peuvent être mergés
  • Envoi de l'appel aux testeurs

1 Semaine Avant la Fusion

2 Jours Avant la Fusion

Jour de la fusion

  • qmk_firmware git commands
    • git checkout future
    • git pull --ff-only
    • git rebase origin/master
    • Modifie readme.md
      • Supprimer les notes à propos de future
    • Regroupe ChangeLog dans un fichier.
    • git commit -m 'Merge point for <DATE> Breaking Change'
    • git push origin future
  • Actions sur Github
    • Crée un PR pour future
    • S'assurer que Travis ne relève aucun problème
    • Fusion le PR future