> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Politique de maintenance

## Prise en charge des versions pour les langages et les paquets

Chez AppSignal, nous avons une politique de support pour tous nos paquets d'intégration. Celle-ci définit quelle compatibilité nous maintenons avec les langages de programmation et les paquets avec lesquels nous nous intégrons. Nous pouvons abandonner la prise en charge de certaines versions de langages de programmation et de paquets au fil du temps. Consultez cette page pour notre politique. Cette politique peut être modifiée à l'avenir.

## Raisonnement

Il existe de nombreuses versions de langages de programmation et de paquets. Nous ne pouvons pas raisonnablement tous les prendre en charge. Cela prendrait trop de temps à maintenir et limiterait notre travail à des syntaxes et fonctionnalités spécifiques des langages/paquets.

## Langages de programmation

Nous prenons en charge les versions maintenues d'un langage de programmation avec lequel nous nous intégrons. Une fois qu'une version atteint sa fin de vie (EOL), nous abandonnerons la prise en charge dans la prochaine version majeure ou mineure d'une intégration. Si possible, nous le faisons en mettant à jour l'exigence de version du langage dans nos définitions de paquets afin qu'il échoue à s'installer sur les versions plus anciennes.

Consultez la politique de maintenance par langage avec lequel nous nous intégrons ci-dessous. Si un langage que nous prenons en charge n'a pas de politique de maintenance, nous prendrons par défaut en charge les trois dernières versions majeures si possible.

* [Politique de maintenance Ruby](https://www.ruby-lang.org/en/downloads/branches/)
* [Politique de maintenance Elixir](https://hexdocs.pm/elixir/compatibility-and-deprecations.html)
  * La [prise en charge d'Erlang OTP](https://hexdocs.pm/elixir/compatibility-and-deprecations.html#compatibility-between-elixir-and-erlang-otp) est basée sur quelle version d'Elixir prend en charge quelle version d'OTP.
* [Politique de maintenance Node.js](https://nodejs.org/en/about/releases/)
  * Nous ne prenons en charge que les versions sous « Maintenance LTS », « Active LTS » et « Current ».
* [Politique de maintenance Python](https://devguide.python.org/versions/)
  * Nous ne prenons en charge que les versions qui sont dans les états « feature », « bugfix » et « security ».
* Politique de support JavaScript front-end.
  * Nous visons la compatibilité avec la plupart des navigateurs majeurs, jusqu'à Internet Explorer 9. Tous les navigateurs plus anciens que celui-ci ne peuvent être pris en charge qu'au mieux, et la pleine fonctionnalité ne peut être garantie.
  * Il prend également en charge différentes cibles :
    * Applications Electron
    * Processus à courte durée de vie
    * Fonctions serverless
    * Applications générées statiquement
    * Applications React Native/Expo

## Paquets

Nous prenons en charge les versions maintenues d'un paquet avec lequel nous nous intégrons. Une fois qu'une version de paquet atteint sa fin de vie (EOL), nous abandonnerons la prise en charge dans la prochaine version majeure ou mineure d'une intégration. Si possible, nous le faisons en mettant à jour l'exigence de version du paquet dans nos définitions de paquets ou d'une autre manière.

Tous les paquets n'ont pas de politique de maintenance, ne prenant en charge que la dernière version de leur paquet. Dans ce cas, nous ne prenons en charge que les trois dernières versions majeures, ou les versions mineures si un paquet ne publie presque jamais de version majeure. Cette prise en charge est dans la limite du raisonnable, tant que nous pouvons continuer à le prendre en charge sans passer un temps excessif à maintenir la compatibilité.

## Intégrations plus récentes

Pour les nouvelles intégrations (langages de programmation et paquets), cette politique de support ne s'applique pas. AppSignal ne ciblera d'abord que la version maintenue, ou la dernière version, d'un langage/paquet. Nous ne prendrons pas en charge les versions plus anciennes immédiatement, sauf si pertinent.

## Branches Git

Pendant le processus de support, une application peut avoir testé un correctif ou une nouvelle fonctionnalité sur demande, en incluant l'une des intégrations AppSignal via Git par le biais d'une branche Git spécifique. Ces branches appartiennent à des Pull Requests qui sont finalement soit fusionnées, soit fermées. Ensuite, la branche qui appartient à la Pull Request est **supprimée après six mois**. Cela peut prendre plus de temps parfois, mais aucune garantie n'est donnée concernant la durée de vie des branches au-delà de ce point.

Veuillez mettre à jour votre intégration vers la dernière version publiée des paquets dès que possible.

Nous vous conseillons fortement de *ne jamais* déployer une application dans son environnement de production lorsqu'elle installe une intégration AppSignal via Git.