1
0
Fork 0

[Docs] French translation - Breaking Changes section (#6966)

* Translated breaking_changes.md in French

* Translated ChangeLog/20190830.md to French

* Update docs/fr-FR/breaking_changes.md

Co-Authored-By: Max Rumpf <max.rumpf1998@gmail.com>

* Fix comments from @zekth

Co-Authored-By: Vincent LE GOFF <g_n_s@hotmail.fr>
This commit is contained in:
Xavier Hahn 2019-10-10 00:45:41 +02:00 committed by noroadsleft
parent e58343596a
commit da3ff89fac
3 changed files with 162 additions and 3 deletions

View file

@ -0,0 +1,52 @@
# QMK Breaking Change - 30 août 2019
Quatre fois par an, QMK lance un processus pour fusionner les 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 n'effectuons ces changements que 4 fois par an afin que les utilisateurs n'aient pas peur de casser leurs keymaps en mettant à jour leur version de QMK.
Ce document présente les fusions de Breaking Change. Voici la liste des changements.
## Formattage de code Core avec clang-format
* Tous les fichiers core (`drivers/`, `quantum/`, `tests/`, et `tmk_core/`) seront formattés avec clang-format
* Un processus travis pour reformatter les PRs lors de la fusion a été mis en place
* Vous pouvez utiliser la nouvelle commande CLI `qmk cformat` afin de formatter avant de soumettre votre PR si vous le souhaitez.
## Nettoyage des descripteurs LUFA USB
* Nettoyage du code lié aux descripteurs USB HID sur les claviers AVR, afin de les rendre plus simple à lire et compréhensibles
* Plus d'information: https://github.com/qmk/qmk_firmware/pull/4871
* Normalement pas de changement de fonctionnement et aucune keymap modifiée.
## Migration des entrées de `ACTION_LAYER_MOMENTARY()` dans `fn_actions` vers des keycodes `MO()`
* `fn_actions` est déprécié, et ses fonctionnalités ont été remplacées par des keycodes directs et `process_record_user()`
* Supprimer cette fonctionnalité obsolète devrait aboutir à une réduction importante de la taille du firmware et de la complexité du code
* Il est recommandé que toutes les keymaps affectées remplacent `fn_actions` vers les fonctionnalités de [keycode custom](https://docs.qmk.fm/#/custom_quantum_functions) et [macro](https://docs.qmk.fm/#/feature_macros)
## Mise à jour Atreus vers les conventions de codage courantes
* Les doublons include guards ont contourné le comportement de traitement des headers attendu
* Il est recommandé pour toutes les keymaps affectées de supprimer le doublon de `<keyboard>/config.h` et `<keyboard>/keymaps/<user>/config.h` et de ne garder que des surcharges au niveau keymap
## Récupération des changements de fichier keymap langage de la fork ZSA
* Corrige une issue dans le fichier `keymap_br_abnt2.h` qui inclut la mauvaise souce (`keymap_common.h` au lieu de `keymap.h`)
* Met à jour le fichier `keymap_swedish.h` afin d'être spécifique au suédois et plus "nordique" en général.
* Toutes les keymaps qui utilisent ceci devront supprimer `NO_*` et le remplacer par `SE_*`.
## Mise à jour du repo afin d'utiliser LUFA comme un sous-module git
* `/lib/LUFA` supprimé du dépôt
* LUFA, définis comme un sous-module, pointe vers qmk/lufa
* Ceci devrait ajouter plus de flexibilité vers LUFA, et nous permet de garder le sous-module à jour bien plus facilement. Il avait environ 2 ans de retard, sans manière simple de corriger. Ce changement devrait simplifier la mise à jour dans le futur.
## Migration des entrées `ACTION_BACKLIGHT_*()` dans `fn_actions` vers des keycodes `BL_`
* `fn_actions` est déprécié, et ses fonctionnalités ont été remplacées par des keycodes directs et `process_record_user()`
* Toutes les keymaps utilisant ces actions doivent avoir les clés `KC_FN*` remplacées par les clés `BL_*` équivalentes
* Si vous utilisez actuellement `KC_FN*` vous devrez remplacer `fn_actions` avec les fonctionnalités de [keycode custom](https://docs.qmk.fm/#/custom_quantum_functions) et [macro](https://docs.qmk.fm/#/feature_macros)
## Remplacer l'alias `KC_DELT` par `KC_DEL`
* `KC_DELT` était un alias redondant et non documenté pour `KC_DELETE`
* Il a été supprimé et toutes ses utilisations ont été remplacées par l'alias plus courant `KC_DEL`
* Environ 90 keymaps (surtout des boards ErgoDox) ont été modifiées à cette fin

View file

@ -16,10 +16,10 @@
* [Comment utiliser GitHub](fr-FR/getting_started_github.md) * [Comment utiliser GitHub](fr-FR/getting_started_github.md)
* [Trouver de l'aide](fr-FR/getting_started_getting_help.md) * [Trouver de l'aide](fr-FR/getting_started_getting_help.md)
**En Anglais** * [Breaking changes](fr-FR/breaking_changes.md)
* [30 août 2019](fr-FR/ChangeLog/20190830.md)
* [Changements non rétro-compatibles](breaking_changes.md) **En Anglais**
* [30 Aout 2019](ChangeLog/20190830.md)
* [FAQ](faq.md) * [FAQ](faq.md)
* [FAQ Générale](faq_general.md) * [FAQ Générale](faq_general.md)

View file

@ -0,0 +1,107 @@
# 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?
* [30 août 2019](ChangeLog/20190830.md)
## Quand va être le prochain Breaking Change?
Le prochain Breaking Change est planifié pour le 29 novembre.
### Dates importantes
* [x] 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 regardez la liste des [labels `breaking_change`](https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+label%3Abreaking_change+is%3Apr). 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
* [ ] Discord
* [ ] GitHub PR
* [ ] https://reddit.com/r/olkb
## 1 Semaine Avant la Fusion
* Annonce que master sera fermée entre <2 jours avant> à <Jour de la fusion>
* [ ] Discord
* [ ] GitHub PR
* [ ] https://reddit.com/r/olkb
## 2 Jours Avant la Fusion
* Annonce que master est fermé pour 2 jours
* [ ] Discord
* [ ] GitHub PR
* [ ] https://reddit.com/r/olkb
## 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`