---
title: 'Announcement: Pydantic v2.11 Release'
description: >-
  What’s new in Pydantic 2.11: Faster parsing, reduced memory usage for Pydantic
  model schemas, extended typing features, and other enhancements
date: '2025-03-27'
authors:
  - Sydney Runkle
  - Victorien Plot
categories:
  - Release
  - Performance Improvements
  - New Features
canonical: 'https://pydantic.dev/articles/pydantic-v2-11-release'
---

> Markdown version of [Announcement: Pydantic v2.11 Release](https://pydantic.dev/articles/pydantic-v2-11-release) — the canonical HTML page.
>
> By Sydney Runkle, [Victorien Plot](https://pydantic.dev/authors/victorien-plot.md) · 2025-03-27 · Release, Performance Improvements, New Features
>
> Related: [Announcement: Pydantic v2.13 Release](https://pydantic.dev/articles/pydantic-v2-13-release.md) · [Announcement: Pydantic v2.12 Release](https://pydantic.dev/articles/pydantic-v2-12-release.md)
>
> All articles: [/articles.md](https://pydantic.dev/articles.md) · Site index: [/llms.txt](https://pydantic.dev/llms.txt)

---

<script src="https://cdnjs.cloudflare.com/ajax/libs/Chart.js/4.4.1/chart.umd.js"></script>

[Pydantic v2.11](https://github.com/pydantic/pydantic/releases/tag/v2.11.0) is here!
You can install it now from [PyPI](https://pypi.org/project/pydantic/):

```bash
pip install --upgrade pydantic
```

This release features the work of over 50 contributors (!) and brings major performance improvements and impactful new features.

Highlights include:
* [Significantly faster schema build times (startup times)](#speeding-up-schema-build-times)
* [Reduced memory usage for pydantic model schemas](#reducing-memory-usage)
* [Improved alias configuration API](#improved-alias-configuration-api)
* [Python 3.8 support dropped](#python-38-support-dropped)
* [Official support](#official-support-for-pep-695-and-pep-696) for [PEP 695](https://peps.python.org/pep-0695/) and [PEP 696](https://peps.python.org/pep-0696/)

You can see the full changelog on [GitHub](https://github.com/pydantic/pydantic/compare/v2.10.6...v2.11.0/).

:::commend
The Pydantic team's ongoing work on performance, features, and issue triage is made possible by customers of our
observability platform, [Pydantic Logfire](https://pydantic.dev/logfire). We're biased, but we think it's the best
option for modern apps. If you want to support Pydantic and our open source work, please give it a try!
:::

## Quick Reference:

* [Performance Improvements](#performance-improvements)
* [New Features](#new-features)
* [Changes](#changes)

## Performance Improvements

We've worked hard in v2.11 to speed up schema build times and reduce memory usage for Pydantic models.

:::note
Long standing issues of Pydantic V2 have been startup performance and memory usage.
With V2, Pydantic switched to perform data validation and serialization in Rust via the
[`pydantic-core`](https://github.com/pydantic/pydantic-core/) library.
To be able to communicate *how* validation and serialization should be performed by `pydantic-core`,
Pydantic uses core schemas, built by analyzing the model definitions (type hints, validators, etc).
More information can be found in Pydantic's [architecture documentation](https://pydantic.dev/docs/validation/latest/internals/architecture/).

Inherently, building core schemas takes time and space. In v2.11, we focused on reducing said time and space 🚀.
:::

To showcase the improvements of this release, we will use one of our large benchmark files, the
[kubernetes model file benchmark](https://gist.github.com/Viicos/bd9b3b0e3fbee62838626b07b311f3af)
(provided by a community member helping us to troubleshoot performance).

The following table shows results across different Pydantic versions (run on an M4 Mac):

| Pydantic Version | Startup Time (seconds) | Total Memory Allocated | Final Memory Usage |
|------------------|------------------------|------------------------|--------------------|
| 2.7.2            | 14.06                  | 8.954 GB               | 3.691 GB           |
| 2.8.2            | 14.53                  | 8.957 GB               | 3.970 GB           |
| 2.9.2            | 3.96                   | 2.997 GB               | 634.4 MB           |
| 2.10.6           | 2.77                   | 1.413 GB               | 589.0 MB           |
| 2.11.0           | 1.52                   | 311.3 MB               | 230.8 MB           |

The significant drop in startup time starting in 2.9 is only reproducible in certain scenarios. However,
what does matter are the final improvements shipping with 2.11. Other large benchmarks were also used
during development and showed similar results.

### Speeding Up Schema Build Times

With our recent changes, you can expect up to a 2x improvement in schema build times.

<div style="width: 800px;"><canvas id="StartupPerfChart"></canvas></div>

<script>
Chart = window.Chart;

const startupData = {
    labels: ['2.7.2', '2.8.2', '2.9.2', '2.10.6', '2.11.0'],
    datasets: [
        {
            label: 'Startup Time (seconds)',
            data: [14.06, 14.53, 3.96, 2.77, 1.52],
            borderColor: 'rgb(255, 99, 132)',
            backgroundColor: 'rgba(255, 99, 132, 0.2)',
            fill: false,
        },
    ]
};

const startupConfig = {
    type: 'line',
    data: startupData,
    options: {
        responsive: true,
        maintainAspectRatio: false,
        aspectRatio: 1.3,
        plugins: {
            legend: {
                position: 'top',
            },
            title: {
                display: true,
                text: 'Pydantic Version Startup Performance Metrics'
            }
        },
        scales: {
            y: {
                beginAtZero: true
            }
        }
    }
};

new Chart(document.getElementById('StartupPerfChart'), startupConfig);
</script>

Unlike with the memory optimizations where we can point to one main source of improvement,
the schema build time improvements are the result of a series of small to medium changes.

:::note
Each PR referenced below has [`CodSpeed`](https://codspeed.io/) performance evaluations
linked as a PR comment that show the performance impact of the changes on our robust benchmark suite.
:::

The following PRs contributed significantly to schema build time improvements:

* [Only evaluate `FieldInfo` annotations if required during schema building](https://github.com/pydantic/pydantic/pull/10769): 5-10% improvement
* [Improve annotation application performance](https://github.com/pydantic/pydantic/pull/11186): 3-7% boost (with limited context)
* [Optimize calls to `get_type_ref()`](https://github.com/pydantic/pydantic/pull/10863): up to 30% speedup
* [Refactor and optimize schema cleaning logic](https://github.com/pydantic/pydantic/pull/11244): 15-30% improvement
* [Disable `pydantic-core` schema validation](https://github.com/pydantic/pydantic/pull/11271): 5-10% boost
* [Reuse `SchemaValidator` and `SchemaSerializer` instances](https://github.com/pydantic/pydantic/pull/11402): 5-15% speedup
* [Reuse cached core schemas for parametrized generics](https://github.com/pydantic/pydantic/pull/11434): 67% improvement for our FastAPI startup benchmark
  (only relevant for heavy use of generics)

### Reducing Memory Usage

Recent memory usage optimizations are most relevant for projects with lots of models, particularly those
with nested/reused models. In these cases, you can expect a **2-5x reduction** in memory usage.

<div style="width: 800px;"><canvas id="memoryPerfChart"></canvas></div>

<script>
Chart = window.Chart;

const memoryData = {
    labels: ['2.7.2', '2.8.2', '2.9.2', '2.10.6', '2.11.0'],
    datasets: [
        {
            label: 'Total Memory Allocated (GB)',
            data: [8.954, 8.957, 2.997, 1.413, 0.3113],
            borderColor: 'rgb(54, 162, 235)',
            backgroundColor: 'rgba(54, 162, 235, 0.2)',
            fill: false,
        },
        {
            label: 'Final Memory Usage (GB)',
            data: [3.691, 3.970, 0.6344, 0.589, 0.2308],
            borderColor: 'rgb(75, 192, 192)',
            backgroundColor: 'rgba(75, 192, 192, 0.2)',
            fill: false,
        }
    ]
};

const memoryConfig = {
    type: 'line',
    data: memoryData,
    options: {
        responsive: true,
        maintainAspectRatio: false,
        aspectRatio: 1.3,
        plugins: {
            legend: {
                position: 'top',
            },
            title: {
                display: true,
                text: 'Pydantic Version Memory Performance Metrics'
            }
        },
        scales: {
            y: {
                beginAtZero: true
            }
        }
    }
};

new Chart(document.getElementById('memoryPerfChart'), memoryConfig);
</script>

The main change we implemented to optimize memory consumption was reusing `pydantic-core` `SchemaValidator`
and `SchemaSerializer` structures for models with said structures prebuilt.

Some highlight stats:

* Extreme reduction in total number of allocations, we tested up to almost 7x, but this could be even greater depending on model structure
* Significant reduction in resident memory size — this is probably the **most important** metric for users — our experiments showed results between 2-4x
* Reduction in total memory allocated throughout the entirety of an application's schema build process — 1.5-2x


For the [kubernetes model file benchmark](https://gist.github.com/Viicos/bd9b3b0e3fbee62838626b07b311f3af):

| Metric                 | Before    | After   | Change     | % Change  | Reduction Factor |
|------------------------|-----------|---------|------------|-----------|------------------|
| Resident Memory Size   | 563MB     | 290MB   | -273MB     | -48.5%    | 1.94×            |
| Total Allocations      | 1,969,609 | 586,011 | -1,383,598 | -70.2%    | 3.36×            |
| Total Memory Allocated | 787MB     | 519MB   | -268MB     | -34.1%    | 1.52×            |


Using the [`aiotdlib` library](https://github.com/pylakey/aiotdlib) (containing a lot of auto-generated [models](https://github.com/pylakey/aiotdlib/blob/main/aiotdlib/api/types/all.py)):

| Metric                 | Before    | After   | Change     | % Change  | Reduction Factor |
|------------------------|-----------|---------|------------|-----------|------------------|
| Resident Memory Size   | 884MB     | 212MB   | -672MB     | -76.0%    | 4.17×            |
| Total Allocations      | 5,069,626 | 746,466 | -4,323,160 | -85.3%    | 6.79×            |
| Total Memory Allocated | 1.317GB   | 671MB   | -646MB     | -49.1%    | 1.96×            |


The [main set of changes](https://github.com/pydantic/pydantic-core/pull/1616) was in `pydantic-core`, with the
[corresponding PR in `pydantic`](https://github.com/pydantic/pydantic/pull/11402) showcasing 5-15% improvements in
schema build times, as a nice side effect!

## New Features

### Official Support for PEP 695 and PEP 696

In Python 3.12, [a new syntax](https://docs.python.org/3/reference/compound_stmts.html#type-params)
was introduced to create generic classes. While it incidentally worked with Pydantic models,
the new syntax wasn’t properly supported for other types (dataclasses, named tuples, etc).
In this release, you can now safely make use of the syntax (assuming you are on Python 3.12 or greater):

```python
from pydantic import BaseModel

class Model[T1, T2](BaseModel):
    t1: T1
    t2: 'list[T2]'  # Forward references also work
```

[PEP 695](https://peps.python.org/pep-0695/) also introduced a [new syntax](https://typing.readthedocs.io/en/latest/spec/aliases.html#type-aliases)
to define type aliases. While support for such aliases was added in previous Pydantic versions, this release fixes many bugs and inconsistencies with them.
Here is an example showcasing the use of the [`type` statement](https://docs.python.org/3/reference/simple_stmts.html#type):

```python
from pydantic import TypeAdapter

type MyList[T] = list[T]
type MyDict = dict[str, MyList[int]]

TypeAdapter.validate_python({'test': ['1', 2]})
#> {'test': [1, 2]}
```

Note that PEP 695 type aliases are **treated differently** from “normal”/”old-style” type aliases. For more information,
consult the dedicated [documentation section](https://pydantic.dev/docs/validation/2.11/concepts/types/#named-type-aliases).

---

Additionally, [type variable defaults](https://typing.readthedocs.io/en/latest/spec/generics.html#type-parameter-defaults)
(introduced by [PEP 696](https://peps.python.org/pep-0696/)) are now properly supported.

PR references:

* [PEP 695 support (#11189)](https://github.com/pydantic/pydantic/pull/11189)
* [Type aliases referencing other type aliases (#10809)](https://github.com/pydantic/pydantic/pull/10809)
* [Proper JSON schema generation for type aliases (#11475)](https://github.com/pydantic/pydantic/pull/11475)
* [Better support for type variable defaults (#11332)](https://github.com/pydantic/pydantic/pull/11332)
* [Support type variable defaults referencing other type variables (#11520)](https://github.com/pydantic/pydantic/pull/11520).

### New API to Define Fields with `create_model()`

The API to provide fields to [`create_model()`](https://pydantic.dev/docs/validation/dev/concepts/models/#dynamic-model-creation)
was simplified and supports more use cases. The new syntax is similar to model annotations:

```python
from pydantic import create_model

Model = create_model(
    'Model',
    foo=str,         # Equivalent to `foo: str` on a model
    bar=(int, 123),  # Equivalent to `bar: int = 123` on a model
)
```

In previous Pydantic versions, a field without a default had to be specified as a two-tuple (e.g. `(int, ...)`).
Having multiple [`Annotated` metadata](https://pydantic.dev/docs/validation/dev/concepts/fields/#the-annotated-pattern) wasn’t supported as well.

The documentation can be found [here](https://pydantic.dev/docs/validation/2.11/concepts/models/#dynamic-model-creation).

PR reference: [#11032](https://github.com/pydantic/pydantic/pull/11032).

### Experimental support for free threading

Starting with the CPython 3.13 release, a new [free-threaded build](https://docs.python.org/3/howto/free-threading-python.html) is made available
to disable the [global interpreter lock](https://docs.python.org/3/glossary.html#term-global-interpreter-lock) (GIL). In 2.11, Pydantic added
experimental support for such builds.

However, do note that many unexpected issues can still occur, including during validation and/or serialization. The tests we run in CI are currently
still flaky, and more investigation will be needed to identify whether this is due to CPython 3.13 itself or Pydantic.

## Changes

### JSON Schema

Generated JSON Schemas for [`dict`](https://docs.python.org/3/tutorial/datastructures.html#dictionaries) types now
include an [`additionalProperties`](https://json-schema.org/understanding-json-schema/reference/object#additionalproperties)
keyword with a value of `true` if the value type is [`Any`](https://docs.python.org/3/library/typing.html#typing.Any)
or [`object`](https://docs.python.org/3/library/functions.html#object).

```python
from pydantic import TypeAdapter

print(TypeAdapter(dict[str, object]).json_schema())
#> {'additionalProperties': True, 'type': 'object'}
```

### Improved Alias Configuration API

You [asked](https://github.com/pydantic/pydantic/pull/11468), we listened!
The API for configuring alias use in validation and serialization has been significantly improved.

The new API introduces increased configurability for alias usage via `ConfigDict` settings and runtime flags.
For a full overview of the new API, check out the [aliases documentation](https://pydantic.dev/docs/validation/2.11/concepts/alias/#alias-configuration).

Here are the highlights:

#### New `serialize_by_alias` setting

This was the most requested change to the alias configuration API: to be more consistent with the validation by alias API,
we've added a [`serialize_by_alias`](https://pydantic.dev/docs/validation/2.11/api/pydantic/config/#pydantic.config.ConfigDict.serialize_by_alias)
configuration setting.

`serialize_by_alias` is set to `False` by default for backwards compatibility. In V3, we anticipate changing
the default to `True` to be consistent with the default behavior at validation time (validating by alias by default).

```python
from pydantic import BaseModel, ConfigDict, Field


class Model(BaseModel):
    my_field: str = Field(serialization_alias='my_alias')

    model_config = ConfigDict(serialize_by_alias=True)


m = Model(my_field='foo')
m.model_dump()
#> {'my_alias': 'foo'}
```

#### Changes to alias validation

Up until now, Pydantic was using the alias to validate input data, unless
[`populate_by_name`](https://pydantic.dev/docs/validation/2.11/api/pydantic/config/#pydantic.config.ConfigDict.populate_by_name)
was set to `True` (in which case both the alias and field name could be used).

Pydantic 2.11 introduces two new configuration settings that affect alias validation behavior:
[`validate_by_alias`](https://pydantic.dev/docs/validation/2.11/api/pydantic/config/#pydantic.config.ConfigDict.validate_by_alias)
and [`validate_by_name`](https://pydantic.dev/docs/validation/2.11/api/pydantic/config/#pydantic.config.ConfigDict.validate_by_name).

`validate_by_name` is equivalent to `populate_by_name`, and as such `populate_by_name` is pending deprecation in V3.

By default, `validate_by_alias` is `True` and `validate_by_name` is `False` (backwards compatible).
Having two configuration settings allow for better customization of the validation behavior (for instance, it is
now possible to only validate by name, by setting `validate_by_alias` to `False`).

```python
from pydantic import BaseModel, ConfigDict, Field


class Model(BaseModel):
    my_field: str = Field(validation_alias='my_alias')

    model_config = ConfigDict(validate_by_alias=True, validate_by_name=True)


Model(my_alias='foo')
#> Model(my_field='foo')

Model(my_field='foo')
#> Model(my_field='foo')
```

#### Alias behavior on the validation methods

Two new parameters — `by_alias` and `by_name` — were added on the [validation methods](https://pydantic.dev/docs/validation/dev/concepts/models/#validating-data)
(such as [`model_validate()`](https://pydantic.dev/docs/validation/dev/api/pydantic/base_model/#pydantic.BaseModel.model_validate))
to better control the alias validation behavior.

These settings were introduced to be more consistent with the serialization by alias API, which offers a runtime flag.

By default, `by_alias` is `True` and `by_name` is `False`. Runtime flags surpass model boundaries (unlike config settings),
so they can also be used to override model configuration at validation time.

```python
from pydantic import BaseModel, Field


class Model(BaseModel):
    my_field: str = Field(validation_alias='my_alias')


Model.model_validate(
    {'my_alias': 'foo'}, by_alias=True, by_name=True
)
#> Model(my_field='foo')

Model.model_validate(
    {'my_field': 'foo'}, by_alias=True, by_name=True
)
#> Model(my_field='foo')
```

PR references: [`pydantic` changes](https://github.com/pydantic/pydantic/pull/11468)
and [`pydantic-core` changes](https://github.com/pydantic/pydantic-core/pull/1640)

### Python 3.8 Support Dropped

As per Pydantic’s [policy](https://pydantic.dev/docs/validation/latest/get-started/version-policy/#support-for-python-versions),
support for Python 3.8 was dropped in this release. As a consequence, you can now make use of the new style
generics for built-in types (introduced by [PEP 585](https://peps.python.org/pep-0585/)) on any Python version:

```python
from collections.abc import Sequence

from pydantic import BaseModel

class Model(BaseModel):
    f1: list[int]
    f2: dict[str, bool]
    f3: Sequence[str]
```

The status of the supported Python versions can be found [here](https://devguide.python.org/versions/).

PR reference: [#11258](https://github.com/pydantic/pydantic/pull/11258)

### Deprecation: Annotated `Final` Fields with Defaults

If a field is annotated as [`Final`](https://docs.python.org/3/library/typing.html#typing.Final) and doesn’t have a default value,
it is considered as a [frozen instance field](https://pydantic.dev/docs/validation/dev/concepts/fields/#immutability) by Pydantic. However, if the field
has a default value, the field is currently treated as a [class variable](https://pydantic.dev/docs/validation/2.11/concepts/models/#class-variables):

```python
from typing import Final

from pydantic import BaseModel

class Model(BaseModel):
    a: Final[int]      # a is a "normal" field
    b: Final[int] = 2  # b is a class variable
```

This behavior is coming from the [PEP 591](https://peps.python.org/pep-0591/#semantics-and-examples) specification. It was recently superseded by an
[update](https://github.com/python/typing/pull/1669) in the typing specification, and as such Pydantic will align with the new expected behavior
(i.e. such class variables will be “normal” fields) in V3.

Annotating a field as [`Final`](https://docs.python.org/3/library/typing.html#typing.Final) with a default value will now raise a deprecation warning.
If you are relying on this behavior, consider using the [`ClassVar`](https://docs.python.org/3/library/typing.html#typing.ClassVar) qualifier instead.

PR reference: [#11168](https://github.com/pydantic/pydantic/pull/11168).

### Deprecation: Accessing `model_fields` on an instance

Accessing the [`model_fields`](https://pydantic.dev/docs/validation/dev/api/pydantic/base_model/#pydantic.BaseModel.model_fields) and
[`model_computed_fields`](https://pydantic.dev/docs/validation/dev/api/pydantic/base_model/#pydantic.BaseModel.model_computed_fields)
attributes on model instances is deprecated:

```python
from pydantic import BaseModel

class Model(BaseModel):
    a: int

my_model = Model(a=1)
my_model.model_fields  # ❌ will not work in V3
Model.model_fields     # ✅ will continue to work
```

This is done in an effort to clean up the `BaseModel` class namespace (so that `model_fields` can actually be used as a field name).

PR reference: [#11169](https://github.com/pydantic/pydantic/pull/11169).

### Constraint support changes for various types

In v2.10 and earlier, types such as [`Mapping`](https://docs.python.org/3/library/collections.abc.html#collections.abc.Mapping),
[`Path`](https://docs.python.org/3/library/pathlib.html#pathlib.Path) (and other path-like types) and
[`deque`](https://docs.python.org/3/library/collections.html#collections.deque) supported some constraints that weren't fully
appropriate for the underlying types/validators. In v2.11, we've moved to a more standard schema building approach for these types,
which resulted in a few changes to the constraints that are supported.

For [`Path`](https://docs.python.org/3/library/pathlib.html#pathlib.Path) types, support for constraints like
`min_length`, `max_length`, and `strip_whitespace`/other string constraints has been removed, and should be implemented
via custom validators instead.

For [`deque`](https://docs.python.org/3/library/collections.html#collections.deque) types, `max_length` constraints are still enforced,
but we no longer monkeypatch  the `max_length` constraint with the [`maxlen`](https://docs.python.org/3/library/collections.html#collections.deque.maxlen)
attribute from the validated [`deque`](https://docs.python.org/3/library/collections.html#collections.deque) instance. If you desire this edge case-y behavior,
you should implement it via a [custom validator](https://pydantic.dev/docs/validation/2.11/concepts/validators/).

For [`Mapping`](https://docs.python.org/3/library/collections.abc.html#collections.abc.Mapping) like types, we don't anticipate changes to the allowed constraints,
but we always recommend custom validator usage for anything that isn't a relatively standard constraint.

PR references:

* [`Path` like changes](https://github.com/pydantic/pydantic/pull/10846)
* [`deque` changes](https://github.com/pydantic/pydantic/pull/11239)
* [`Mapping` changes](https://github.com/pydantic/pydantic/pull/11247)

## Bonus: We've added a Third Party Test Suite!

Pydantic v2.11 is launching backed by a new third party test suite, which is a collection of tests
from other popular libraries run nightly against the `main` branch.
We also run this test suite on PRs with changes that have the potential to affect Pydantic users.

These tests help to catch regressions in Pydantic and ensure that upgrades to Pydantic
are smooth for library maintainers and users alike.

Thus far, we've added tests against:

* [FastAPI](https://github.com/fastapi/fastapi)
* [SQLModel](https://github.com/fastapi/sqlmodel/)
* [openapi-python-client](https://github.com/openapi-generators/openapi-python-client)
* [Langchain](https://github.com/langchain-ai/langchain)
* [BeanieODM](https://github.com/BeanieODM/beanie)
* [Polar](https://github.com/polarsource/polar)
* [Pandera](https://github.com/unionai-oss/pandera)
* [ODMantic](https://github.com/art049/odmantic)
* [BentoML](https://github.com/bentoml/BentoML)
* [semantic-kernel](https://github.com/microsoft/semantic-kernel)

This [project](https://github.com/pydantic/pydantic/issues/11160) is still ongoing!
If you'd like to add your library to the test suite, follow
[this guide](https://pydantic.dev/docs/validation/dev/get-started/contributing/#adding-your-library-as-part-of-pydantics-third-party-test-suite)
to learn more.

## Conclusion

We're excited to share Pydantic v2.11, the most performant version of Pydantic yet.
If you have any questions or feedback, please open a [GitHub discussion](https://github.com/pydantic/pydantic/discussions/new/choose).
If you encounter any bugs, please open a [GitHub issue](https://github.com/pydantic/pydantic/issues/new/choose).

Thank you to all of our contributors for making this release possible!
We would especially like to acknowledge [@MarkusSintonen](https://github.com/pydantic/pydantic/commits?author=MarkusSintonen)
for his significant contributions to improving schema build times as a part of this release.

## Pydantic Logfire

If you're enjoying Pydantic, you might **really** like [Pydantic Logfire](https://pydantic.dev/logfire), a new observability tool
built by the team behind Pydantic. You can now [try Logfire](https://logfire.pydantic.dev/login/) for free.
We'd love it if you'd join the [Pydantic Logfire Slack](https://pydantic.dev/docs/logfire/get-started/help/#:~:text=Pydantic%20Logfire%20Slack) and
let us know what you think!