Version support for languages and packages
At AppSignal we have a support policy for all our integration packages. This defines what compatibility we maintain with programming languages and packages we integrate with. We may drop support for some versions of programming languages and packages over time. Consult this page for our policy. This policy may be subject to change in the future.Rationale
There are a lot of versions of programming languages and packages out there. We can’t realistically support them all. It would take too much time to maintain and would limit our work to specific syntax and features of the languages/packages.Programming languages
We support the maintained versions of a programming language we integrate with. Once a release becomes End of Life (EOL), we will drop support in the next major or minor release of an integration. If possible, we do this by updating the language version requirement in our package definitions so that it will fail to install on older versions. Consult the maintenance policy per language we integrate with below. If a language we support does not publish a maintenance policy, we determine support case by case based on recent stable releases and what we can maintain reasonably.- Ruby maintenance policy
- Elixir maintenance policy
- Erlang OTP support is based on which version of Elixir supports which OTP version.
- Node.js maintenance policy
- We only support the releases under “Maintenance LTS”, “Active LTS” and “Current”.
- Python maintenance policy
- We only support the releases that are in the “feature”, “bugfix” and “security” states.
- Front-end JavaScript support policy.
- We aim for compatibility for most major browsers, down to Internet Explorer 9. All browsers older than this can only supported on a “best effort” basis, and full functionality cannot be guaranteed.
- It also supports different targets:
- Electron apps
- Short-lived processes
- Serverless functions
- Statically generated apps
- React Native/Expo apps
Packages
We support the maintained versions of a package we integrate with. Once a package version becomes End of Life (EOL), we will drop support in the next major or minor release of an integration. If possible, we do this by updating the package version requirement in our package definitions or in some other way. Not all packages publish a maintenance policy. In those cases, we determine support case by case based on recent stable releases and what we can maintain reasonably. Older package versions may continue to work, but we do not guarantee support or fixes for them.Planning an upgrade from an older version
Older AppSignal package versions may still install and run, but they are legacy and can depend on unsupported runtimes, operating systems, frameworks, or packages. We recommend upgrading to a supported version, as we do not fully support older ones. The Ruby and Elixir tables below map each AppSignal release range to the minimum language version it requires. They are a quick reference — the authoritative source is each package’s page on its registry, which lists the requirement for every release.Ruby
The
4.x gemspec allows Ruby 2.7+, but some installs on Ruby 3.0 and earlier can still fail because of the JSON::Fragment issue. The appsignal gem on RubyGems shows the required Ruby version for each release.
To upgrade across major gem versions, follow the upgrade guide from 2 to 3 or the upgrade guide from 3 to 4.
Elixir
The minimum Elixir version changed at package
2.0.0. The appsignal package on Hex shows the required Elixir version for each release. To move to the latest package version, follow the installation guide.
Node.js
The@appsignal/nodejs package declares its required Node.js version in package.json. To upgrade across major versions, follow the 3.x migration guide.