Pending inclusion or exclusion of #13824, can I please get confirmation that we are happy to release over the next day or two, @scikit-learn/core-devs ? Thanks.

I think that #13816 needs to be backported since #13302 has been merged.

I like #13824. Nothing blocking the release on my side, thanks for your fantastic work !

After merge:

• update news and what's new date in master and release branch
• create tag
• change scikit-learn.github.io/stable symlink
• update dependencies and release tag at https://github.com/MacPython/scikit-learn-wheels
• twine the wheels to PyPI when that's green
• https://github.com/scikit-learn/scikit-learn/releases draft
• confirm bot detected at https://github.com/conda-forge/scikit-learn-feedstock and wait for merge
• https://github.com/scikit-learn/scikit-learn/releases publish
• announce on mailing list
• (regenerate Dash docs: https://github.com/Kapeli/Dash-User-Contributions/tree/master/docsets/Scikit)

Forgot that we want to update the roadmap, per #13809, too.

Is it possible to remove the experimental tag in ColumnTransformer (and fetch_openml maybe)? I don't like the inconsistency between experimental features.
For fetch_openml, we said that "The API is experimental in version 0.20". I think we should at least update the note.
We tag ColumnTransformer as experimental, but we still use a deprecation cycle when we change the API interface of make_column_transformer, so I'm still confused about the definition of experimental.

We tag ColumnTransformer as experimental, but we still use a deprecation cycle when we change the API interface of make_column_transformer, so I'm still confused about the definition of experimental.

The problem there was partially that our core devs had been teaching with an experimental interface, so TBH, we were merely protecting our own. I think the explicit consent we have now introduced mitigates this unclarity.

I'm okay with removing experimental tag from ColumnTransformer. Make a PR?

I'd leave it on fetch_openml. There I think we might still want to change how we handle heterogeneous types etc by default. I agree it's inconsistent in terms of how experimental is demonstrated in the API, but we can't change history.

@jnothman If we want to change the API of an experimental feature, do we need a deprecation cycle?

If we want to change the API of an experimental feature, do we need a deprecation cycle?

No, but we can still choose to have one.