Skip to content

add first version translation faq-versioning.md #91

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 26 commits into from
Mar 13, 2019
Merged
Changes from all commits
Commits
Show all changes
26 commits
Select commit Hold shift + click to select a range
819427f
add first version translation faq-versioning.md
salimbenfarhat Mar 7, 2019
960b26d
add first version translation faq-versioning.md
salimbenfarhat Mar 7, 2019
f91a6fb
add first version translation faq-versioning.md
salimbenfarhat Mar 7, 2019
7ceb63d
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
12a5728
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
83f097b
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
322952e
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
d8269cd
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
fc49087
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
0badf4e
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
703f2c8
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
6433b30
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
a8fe9ad
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
d80b2c1
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
9c4b914
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
20158ef
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
692c8a1
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
f515e62
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
08d123a
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
b9ace97
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
b231a65
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
e387240
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
21eadf7
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
2610272
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
7f3bc80
Update content/docs/faq-versioning.md
tdd Mar 13, 2019
9f27401
Final tweaks
tdd Mar 13, 2019
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 26 additions & 24 deletions content/docs/faq-versioning.md
Original file line number Diff line number Diff line change
@@ -1,48 +1,50 @@
---
id: faq-versioning
title: Versioning Policy
title: Politique de gestion des versions
permalink: docs/faq-versioning.html
layout: docs
category: FAQ
---

React follows [semantic versioning (semver)](https://semver.org/) principles.
React suit les principes de [gestion sémantique de version (semver)](https://semver.org/lang/fr/).

That means that with a version number **x.y.z**:
Ça signifie qu'avec un numéro de version de type **x.y.z** :

* When releasing **breaking changes**, we make a **major release** by changing the **x** number (ex: 15.6.2 to 16.0.0).
* When releasing **new features**, we make a **minor release** by changing the **y** number (ex: 15.6.2 to 15.7.0).
* When releasing **bug fixes**, we make a **patch release** by changing the **z** number (ex: 15.6.2 to 15.6.3).
* Pour publier des **modifications cassant la compatibilité ascendante**, nous changeons de **version majeure** en modifiant le nombre **x** (ex. 15.6.2 à 16.0.0).
* Pour publier des **nouvelles fonctionnalités**, nous changeons de **version mineure** en modifiant le nombre **y** (ex. 15.6.2 à 15.7.0).
* Pour publier des **corrections de bugs**, nous changeons de **version de correctif** en modifiant le nombre **z** (ex. 15.6.2 à 15.6.3).

Major releases can also contain new features, and any release can include bug fixes.
Les versions majeures peuvent également contenir de nouvelles fonctionnalités, et toute version peut inclure des corrections de bugs.

### Breaking Changes {#breaking-changes}
### Ruptures de compatibilité ascendante {#breaking-changes}

Breaking changes are inconvenient for everyone, so we try to minimize the number of major releases – for example, React 15 was released in April 2016 and React 16 was released in September 2017; React 17 isn't expected until 2019.
Personne n’aime perdre en compatibilité ascendante, nous essayons donc de minimiser le nombre de versions majeures ; par exemple, React 15 est sorti en avril 2016 et React 16 en septembre 2017 ; React 17 n'est pas prévu avant 2019.

Instead, we release new features in minor versions. That means that minor releases are often more interesting and compelling than majors, despite their unassuming name.
Au lieu de ça, nous publions les nouvelles fonctionnalités dans des versions mineures. Celles-ci sont souvent plus intéressantes et motivantes que les majeures, malgré leur nom modeste.

### Commitment to Stability {#commitment-to-stability}
### Nos engagements en termes de stabilité {#commitment-to-stability}

As we change React over time, we try to minimize the effort required to take advantage of new features. When possible, we'll keep an older API working, even if that means putting it in a separate package. For example, [mixins have been discouraged for years](/blog/2016/07/13/mixins-considered-harmful.html) but they're supported to this day [via create-react-class](/docs/react-without-es6.html#mixins) and many codebases continue to use them in stable, legacy code.
À mesure que nous améliorons React, nous essayons d'abaisser la barrière d'entrée pour tirer parti des nouvelles fonctionnalités. Chaque fois que possible, nous continuons à prendre en charge une vieille API, même si ça implique de la placer dans un module séparé. Par exemple, [les mixins sont découragés depuis des années](/blog/2016/07/13/mixins-considered-harmful.html) mais ils restent pris en charge à ce jour [via create-react-class](/docs/react-without-es6.html#mixins) et de nombreuses bases de code continuent de les utiliser dans du code historique stable.

Over a million developers use React, collectively maintaining millions of components. The Facebook codebase alone has over 50,000 React components. That means we need to make it as easy as possible to upgrade to new versions of React; if we make large changes without a migration path, people will be stuck on old versions. We test these upgrade paths on Facebook itself – if our team of less than 10 people can update 50,000+ components alone, we hope the upgrade will be manageable for anyone using React. In many cases, we write [automated scripts](https://github.com/reactjs/react-codemod) to upgrade component syntax, which we then include in the open-source release for everyone to use.
Plus d'un million de développeurs utilisent React, qui maintiennent collectivement des millions de composants. La base de code de Facebook contient à elle seule plus de 50 000 composants React.
Ça signifie que nous devons faciliter au maximum la mise à niveau vers les nouvelles versions de React ; si nous apportons des modifications importantes sans fournir d’aide à la migration, les utilisateurs resteront bloqués sur les anciennes versions. Nous testons ces approches de mise à niveau sur Facebook même : si notre équipe de moins de 10 personnes peut mettre à jour plus de 50 000 composants à elle seule, nous espérons que la mise à niveau sera gérable pour toute personne utilisant React. Dans de nombreux cas, nous écrivons des [scripts automatisés](https://github.com/reactjs/react-codemod) pour mettre à niveau la syntaxe des composants, que nous incluons ensuite dans la version libre de notre code source pour que chacun·e puisse les utiliser.

### Gradual Upgrades via Warnings {#gradual-upgrades-via-warnings}
### Mises à niveau progressives grâce aux avertissements {#gradual-upgrades-via-warnings}

Development builds of React include many helpful warnings. Whenever possible, we add warnings in preparation for future breaking changes. That way, if your app has no warnings on the latest release, it will be compatible with the next major release. This allows you to upgrade your apps one component at a time.
Les versions de développement de React incluent de nombreux avertissements utiles. Dans la mesure du possible, nous ajoutons des avertissements en prévision de futurs changements radicaux. Ainsi, si votre application ne contient aucun avertissement sur la dernière version, elle sera compatible avec la prochaine version majeure. Ça vous permet de mettre à niveau vos applications composant par composant.

Development warnings won't affect the runtime behavior of your app. That way, you can feel confident that your app will behave the same way between the development and production builds -- the only differences are that the production build won't log the warnings and that it is more efficient. (If you ever notice otherwise, please file an issue.)
Les avertissements de développement n'affecteront pas le comportement d'exécution de votre application. De cette façon, vous pouvez être sûr·e que votre application se comportera de la même façon entre les versions de développement et de production. La seule différence, c’est que la version de production n'émettra pas les avertissements et qu'elle sera plus efficace. (Si vous remarquez le contraire, veuillez créer une *issue* dans le dépôt GitHub.)

### What Counts as a Breaking Change? {#what-counts-as-a-breaking-change}
### Qu'est ce qui constitue une rupture de compatibilité ? {#what-counts-as-a-breaking-change}

In general, we *don't* bump the major version number for changes to:
En général, nous *n’élevons pas* le numéro de version majeure pour les modifications apportées aux aspects suivants :

* **Development warnings.** Since these don't affect production behavior, we may add new warnings or modify existing warnings in between major versions. In fact, this is what allows us to reliably warn about upcoming breaking changes.
* **APIs starting with `unstable_`.** These are provided as experimental features whose APIs we are not yet confident in. By releasing these with an `unstable_` prefix, we can iterate faster and get to a stable API sooner.
* **Alpha and canary versions of React.** We provide alpha versions of React as a way to test new features early, but we need the flexibility to make changes based on what we learn in the alpha period. If you use these versions, note that APIs may change before the stable release.
* **Undocumented APIs and internal data structures.** If you access internal property names like `__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED` or `__reactInternalInstance$uk43rzhitjg`, there is no warranty. You are on your own.
* **Avertissements de développement.** Dans la mesure où ils n'affectent pas le comportement de production, nous nous réservons le droit d’ajouter de nouveaux avertissements ou de modifier les avertissements existants entre les versions majeures. En fait, c’est ce qui nous permet de vous avertir de manière fiable des changements à venir.
* **API commençant par `unstable_`.** Celles-ci sont fournies en tant que fonctionnalités expérimentales et nous ne sommes pas encore satisfaits de leurs API. En les publiant avec un préfixe `unstable_`, nous pouvons itérer plus rapidement dessus et obtenir une API stable plus tôt.
* **Versions alpha et canary de React.**
Nous fournissons des versions alpha de React afin de tester les nouvelles fonctionnalités à un stade précoce, mais nous avons besoin de la souplesse nécessaire pour apporter des modifications en fonction de ce que nous apprenons au cours de la période alpha. Si vous utilisez ces versions, notez que les API peuvent changer avant la version stable.
* **API non documentées et structures de données internes.** Si vous accédez à des noms de propriété internes tels que `__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED` ou` __reactInternalInstance$uk43rzhitjg`, il n'y a aucune garantie. Débrouillez-vous.

This policy is designed to be pragmatic: certainly, we don't want to cause headaches for you. If we bumped the major version for all of these changes, we would end up releasing more major versions and ultimately causing more versioning pain for the community. It would also mean that we can't make progress in improving React as fast as we'd like.
Cette politique se veut pragmatique : nous ne voulons évidemment pas vous causer de maux de tête. Si nous élevions la version majeure pour tous ces changements, nous finirions par publier plus de versions majeures, ce qui s'avèrerait plus pénible pour la communauté. Ça signifierait également que nous ne pourrions pas améliorer React aussi rapidement que nous le souhaiterions.

That said, if we expect that a change on this list will cause broad problems in the community, we will still do our best to provide a gradual migration path.
Cela dit, si nous nous attendons à ce qu’un changement sur cette liste cause de gros problèmes dans la communauté, nous ferons tout notre possible pour fournir un chemin de migration progressif.