Compatibility
This page documents which Python versions are supported by each slackblocks release line, so you can choose the right line for your runtime.
Each row in the table maps a major slackblocks release line to the oldest Python interpreter that can run it. Minimum Python means that version or any newer supported Python version—not that the release only works on that one version. The status in parentheses tells you whether the line receives current feature development or maintenance fixes only.
Start with the Python version used by your application or deployment environment, then choose the newest slackblocks line whose minimum requirement it meets. For example, Python 3.9 requires slackblocks 1.x, while Python 3.10 and newer can use 3.x.
Support matrix
slackblocks version | Minimum Python | Notes |
|---|---|---|
1.x (maintenance) | 3.8.1 | The last release line to support Python 3.8 and 3.9. |
2.x | 3.10 | Modern typing (X | Y, list[X]), dataclasses with slots, match statements, and other Python 3.10+ features used internally. |
3.x (current) | 3.10 | Corrected number-input bound APIs; the interpreter minimum is unchanged from 2.x. |
If you cannot upgrade Python, pin to the appropriate major version:
- pip (`requirements.txt`)
- poetry (`pyproject.toml`)
- uv (`pyproject.toml`)
slackblocks>=1,<2 # Python 3.8/3.9 friendly
slackblocks>=3,<4 # Python 3.10+; current API
slackblocks = "^1" # Python 3.8/3.9 friendly
slackblocks = "^3" # Python 3.10+; current API
"slackblocks>=1,<2" # Python 3.8/3.9 friendly
"slackblocks>=3,<4" # Python 3.10+; current API
Why we move forward
slackblocks follows the upstream Python release cycle. Once a Python version reaches its official end-of-life, it stops receiving security patches, and we prefer not to ship new feature work targeting unmaintained runtimes.
| Python version | EOL date |
|---|---|
| 3.8 | 2024-10-07 |
| 3.9 | 2025-10-31 |
| 3.10 | 2026-10 |
| 3.11 | 2027-10 |
| 3.12 | 2028-10 |
| 3.13 | 2029-10 |
| 3.14 | 2030-10 |
Bugfix releases on existing lines may continue past these dates on a best-effort basis, but new feature work will target supported Pythons.
Choosing a version
- You're on Python 3.8 or 3.9: install the latest
1.x. - You're on Python 3.10 or newer: install the current
3.xrelease line. - You're starting a new project on a modern Python: prefer
3.xto take advantage of the improved typing surface.
For an upgrade walkthrough from 1.x to 2.x, see the
Migration Guide.
See Installation and the TypeScript API reference for supported versions and native conventions. This page's historical release-line discussion applies to Python.
Go support matrix
The current github.com/nicklambourne/slackblocks/go/v3 module supports Go 1.22
and newer. Its minimum dependency remains github.com/slack-go/slack v0.17.3.
Applications can select a newer SDK without changing the slackblocks module line,
provided their Go toolchain meets that SDK's own requirements.
| slackblocks module line | Tested slack-go/slack version | Minimum Go | Selection |
|---|---|---|---|
Current go/v3 | v0.17.3 | 1.22 | Default minimum dependency; keeps Go 1.22, 1.23 and 1.24 compatible. |
Current go/v3 | v0.23.1 | 1.25 | Explicit application upgrade; tested separately from the minimum dependency. |
Next release on go/v3 (unreleased) | v0.35.0 | 1.26 | Explicit application upgrade with upstream file-URL and interaction-parser security fixes; existing profiles remain supported. |
These are tested combinations, not a guarantee for every intervening or future SDK release. All three profiles use the same slackblocks API. No separate maintenance release line is needed for these combinations.
Choosing an SDK version
For the Go 1.22-compatible combination, select both modules in your application:
go get github.com/nicklambourne/slackblocks/go/v3 github.com/slack-go/slack@v0.17.3
With Go 1.25 or newer, select the retained Go 1.25-compatible SDK:
go get github.com/nicklambourne/slackblocks/go/v3 github.com/slack-go/slack@v0.23.1
For the next release's Go 1.26+ combination, select v0.35.0 explicitly:
go get github.com/nicklambourne/slackblocks/go/v3 github.com/slack-go/slack@v0.35.0
Go's minimal version selection
selects one SDK version for the application, using the highest version required
by its module graph. The core's v0.17.3 requirement is a minimum, not an upper
bound or a conditional version selector. Inspect go list -m all after updating;
another dependency may require a newer SDK or toolchain.
The upstream manifests declare Go 1.22 for v0.17.3,
Go 1.25 for v0.23.1
and Go 1.26 for v0.35.0.
Their toolchain directives suggest a compiler for work in the SDK module,
not an additional minimum for applications importing it. Go may automatically
select a newer toolchain; use GOTOOLCHAIN=local when verifying a fixed compiler
(Go toolchain rules).
Compatibility checks and updates
CI runs Go 1.22, 1.25, 1.26 and stable native checks, and disables
automatic toolchain upgrades in those lanes. The core and the default multi-select
example keep the minimum SDK. The separate go/integrations module selects
v0.35.0 on Go 1.26 and stable; its alternate go125.mod retains v0.23.1 on
Go 1.25, 1.26 and stable. Each profile runs the full native suite, a mixed
native-SDK/slackblocks consumer, and the same multi-select source. All three
profiles must emit the same 15 validated payloads. The v0.35.0 profile also
checks file-URL token restrictions with a recording HTTP client and rejects
query-only interaction payloads using local HTTP requests. These tests make no
live Slack requests.
Dependabot tracks the newer SDK in the integration module. Updates must preserve the minimum core manifest and the retained Go 1.25 profile; they must not silently raise either supported Go floor. A newer SDK requiring a newer compiler needs a separately tested combination, rather than replacing an existing one.
SDK security fixes
Updating slackblocks alone does not select v0.30.1: the core still declares
v0.17.3 as its minimum. Neither v0.17.3 nor v0.23.1 includes the v0.30.1 fix for
GHSA-3q3v-34v2-g88f.
The fix prevents GetFile, GetFileContext and UploadToURL from sending a Slack
token to an arbitrary file URL. Applications using these SDK methods should
select v0.30.1 or newer with Go 1.26+, and review the
upstream upgrade notes.
Retaining an older compatibility profile does not backport this fix.
The v0.35.0 release also fixes
GHSA-pj2x-fjjr-q84c:
InteractionCallbackParse no longer accepts an unsigned URL-query payload
when the signed POST body lacks one. Applications must still verify Slack's
signature over the original request body before parsing. Neither retained older
SDK profile includes this fix; select v0.35.0 or newer explicitly to receive it.
The latest tested SDK, v0.35.0, includes both fixes and retains the Go 1.26 minimum. Review the upstream changes when upgrading from an older SDK:
- v0.31.0 adds non-comparable button values and fields that require keyed struct literals, newly typed rich-text decoding, stricter request-signature validation, POST-based token operations and token-free warning callbacks.
- v0.32.0 makes
CreateCanvasandCreateCanvasContextvariadic. Direct calls still compile, but interfaces, mocks and stored function values may need updating. Added response fields also require keyed struct literals. The release fixes workflow-button serialization and adds code-channel APIs. - v0.33.0 adds layout-block and Slackbot-skills APIs.
- v0.34.0 removes
SetUserAsActive,SetUserAsActiveContextandGetUsersOptionPresence. Team-info methods become variadic; update interfaces and mocks. New struct fields require keyed literals. Stricter block/message decoding can reject an entire event, and experimental typedauth_providerdecoding no longer preserves unknown JSON. Review custom user-connection decoders and Socket Mode handlers: built-in decoders take precedence, and envelopes without inner events now dispatch by their outer event type. - v0.35.0 makes
InteractionCallbackParsereadpayloadonly from the POST body. It also adds huddle fields (use keyed literals), fixes message escaping and context-block serialization, and improves race and retry handling.
These are changes to the SDK's APIs; the slackblocks API and its Go 1.22 default dependency remain unchanged.
The earlier v0.23.1 release also changes empty signing-secret validation in
NewSecretsVerifier;
applications using that SDK feature should review its upstream release notes.
See Installation and the Go API reference for the native API and installation instructions.
See Installation and the Java API reference for supported versions and native conventions. This page's historical release-line discussion applies to Python.
See Installation and the C# API reference for supported versions and native conventions. This page's historical release-line discussion applies to Python.
See Installation and the Ruby API reference for supported versions and native conventions. This page's historical release-line discussion applies to Python.
Rust support policy
Rust support begins with coordinated version 2.6.0. The crate uses edition 2024 with MSRV 1.85.0. CI tests the MSRV and current stable on Linux, plus current stable on macOS and Windows. Raising the MSRV requires an explicit compatibility decision and release notes; dependency updates alone must not narrow supported versions.
Runtime dependencies use compatible Serde/serde_json version requirements.
The checked-in lockfile fixes development builds. Package checks also resolve
fresh consumer dependencies, declared lower bounds, and the consumer-enabled
arbitrary_precision and preserve_order serde_json features.
The optional sending examples have a separate application manifest and lockfile
in rust/integrations. Slack Morphism 2.29.0 and reqwest 0.13.5 are tested there on
Rust 1.85 and stable. Resolver 3 and rust-version = "1.85" select compatible
transitive dependencies, including older Serde helpers and ICU releases where
newer versions require a newer compiler. The mock server is pinned to wiremock
0.6.2 because later versions use Rust 1.88 syntax without declaring that minimum.
These are application/test requirements and never enter the core crate's
manifest or lockfile. A dependency update must pass the same compiler matrix.
Role/vocabulary enums are #[non_exhaustive]; include a wildcard match arm so
new Slack variants can be added. Private fields and validated builders preserve
invariants. No earlier Rust release line exists to migrate from.
PHP support policy
PHP 8.2+ on 64-bit Linux, macOS and Windows is supported. CI runs 8.2 and 8.5 on all three platforms, plus 8.3 and 8.4 on Linux. The minimum remains 8.2 even when development or integration dependencies are updated. PHP itself provides security fixes for 8.2 through December 2026; applications should prefer a currently supported PHP release (PHP support schedule).
The core needs only JSON and PCRE. cURL, JoliCode and Laravel are optional application dependencies tested separately. The minimum integration lock uses Laravel 12; newest compatible versions are also resolved on current PHP.
PHP support began in 2.7.0. Named arguments, enum cases, readonly properties, JSON field names and validation categories are compatibility surfaces. Human-readable error prose may improve. Existing Python, TypeScript, Go, Java, C#, Ruby and Rust minimum versions are unchanged.
Integers preserve the signed 64-bit range, including values above JavaScript's safe-integer limit. Floats use PHP's binary double semantics; arbitrary-precision decimal numbers are not supported. Checked JSON ingress rejects integer overflow, nonfinite values and nonzero numbers that underflow to zero. Strings must be valid UTF-8 and Slack string limits count Unicode code points. Opaque JSON is limited to 128 levels; cyclic graphs and custom object instances are rejected.
Elixir support policy
Elixir 1.16.3 or newer, below 2.0, with a compatible OTP version from 26.2, on 64-bit Linux, macOS and Windows. CI checks Elixir 1.16–1.20 against compatible OTP 26–29 combinations, with minimum/current compiler lanes on all three platforms. Elixir support begins with version 2.8.0. Other implementations' minimum language versions are unchanged.
Runtime dependencies are Jason 1.4.5+ (below 2.0) and Decimal 2.4+ or 3.x. Existing Jason builds may need the installation rebuild step. Req, slack_elixir and Ecto integration tests use a separate project; they add no HTTP, database or web framework dependency to the core package.
Public struct fields, constructor keywords, typespecs, enum atoms, JSON field names and validation categories form the compatibility surface. New optional fields or enum values are additive; match only fields you need and retain a catch-all branch for evolving enums. Error prose may improve. Persist Slack wire JSON instead of serialized BEAM structs across package upgrades.
Integers use BEAM arbitrary precision. Checked JSON decoding preserves integer tokens, rejects duplicate keys and rejects decimal tokens that lose value in the shortest-decimal float round trip, overflow or underflow to nonzero values lost as zero. Integer fields reject decimal/exponent tokens. Decimal scale is not retained; negative zero remains a float. Map ingress cannot recover information discarded by another parser. Opaque JSON nesting is capped at 128 levels. UTF-8 strings are required and limits count Unicode code points, rather than bytes or graphemes.
Erlang can call the same modules using binary strings and keyword tuples; see the tested Rebar3 and standalone release configuration.
Haskell compiler support
Haskell support begins with release 3.1.0. The minimum is GHC 9.6.7.
The package uses GHC2021 and a bounded base dependency; an untested future GHC
series is not implicitly supported.
| GHC series | CI patch | Platforms | Validation |
|---|---|---|---|
| 9.6 | 9.6.7 (minimum) | Linux, macOS, Windows | Full native suites, source archive and external consumers |
| 9.8 | 9.8.4 | Linux | Full native suites |
| 9.10 | 9.10.3 | Linux | Full native suites |
| 9.12 | 9.12.4 | Linux | Full native suites |
| 9.14 | 9.14.1 | Linux, macOS, Windows | Full native suites, source archive and external consumers |
Linux checks independent exact-lower, locked and latest-within-bounds dependency
resolutions. Both Aeson ordered and unordered KeyMap modes run native suites.
Lower bounds include Aeson 2.2.0.0, bytestring 0.11.5.4, text 2.0.2, containers
0.6.7, scientific 0.3.7.0 and vector 0.13.0.0. QuickCheck, HLint and Ormolu are
test/development tools, not consumer dependencies. The HTTP example resolves its
own http-client, http-client-tls and http-types graph on minimum/current GHC.
Version bounds and source compatibility
Use a range such as slackblocks >= 3.2 && < 3.3. Haskell follows the coordinated
package release number; it does not use an independent 0.x numbering scheme.
The Haskell Package Versioning Policy explains why
bounds matter when constructors and exported names evolve. A new closed enum or
role member can affect exhaustive matches; prefer the supplied match… helpers
and review release notes before widening the range. Raising the compiler floor
requires an explicit compatibility decision, not a dependency update shortcut.
Wire and value behavior
Optional Nothing and parsed null omit a field; explicit Just False, zero and
allowed empty values are retained. Block IDs are never generated. Factories set
only documented shared defaults; parsing does not invent absent defaults.
Integer and Scientific avoid binary floating-point loss. Number-input bounds
are decimal text; decimalText converts a Scientific value exactly.
Checked values are immutable. Field records cannot be encoded directly. JSON
ingress validates nested roles and contextual limits; decode additionally
rejects duplicate keys, invalid UTF-8, trailing data and numeric exponents that
overflow Aeson’s Scientific representation. Checked native values and JSON
ingress also reject numbers whose normalized encoding cannot round-trip,
including numbers in metadata and extensions. Bounded integer fields are
range-checked before expanding exponents. Decimal bounds supplied as strings
retain arbitrary-exponent support. Already parsed
Aeson values cannot recover duplicate keys or exponents an earlier parser lost.
Application metadata remains opaque JSON. See ownership and edits
for the native inspect-and-rebuild workflow.