5.4.1 patch release this week?

[joelostblom]

Would everyone be OK if I make a 5.4.1 patch release in the next few days? We're freezing our docker images to use for the semester and I would like to have #3533 included as I think that would be helpful for students. There are no Vega-Lite updates since the last release, so this release would be simple.

As per our recently more explicit effort to align with semantic versioning #3488 we should ideally not include any commits marked with feat. Based on this, I'm thinking I will tag cfab660 a s 5.4.1 so the only two commits are the one I mentioned above and a doc update. If anyone feels strongly about tagging another commit as 5.4.1, let me know.

[binste]

Works for me, thank you Joel! :) Good to get #3533 released.

[MarcoGorelli]

Cool, thanks!

I also wanted to flag marimo-team/marimo#2006 to you. It's the only case I've noticed of someone picking up on the change - they do say "This is nice actually nice since now we can pass polars, pyarrow, etc to altair charts and get back the polars, pyarrow, etc charts.", but also comment that it's technically a breaking change for people registering their own data transformers

I think this may be worth addressing? I'm just looking into it now, sorry for not having got round to it sooner

EDIT: #3549 looks "real" - addressing this now

[joelostblom]

Thanks for fixing that issue, let's wait for it to land as well before releasing then. After that PR is merged, we will have a fix commit after two feat commits on main, so now we can do one of the following:

1. Release the latest commit on main as 5.4.1 although there technically are two feat commits there.
2. Release the latest commit on main as 5.5.0 to more strictly adhere to SemVer.
3. Rebase main to move the fixes and version bumps before the feat commits (what I would have done on a smaller personal project, but maybe not a good idea here).

I'm leaning towards (1), because there are no notable user-facing features added in this release and it is more of a patch with bug fixes, although there technically are feat commits included, but I'm totally fine if we want to do (2) instead. What do you all think?

[dangotbanned]

@joelostblom PR is now merged

• regression: 'csv' data transformer no longer works for Polars #3549

[dangotbanned]

Thanks @joelostblom for the thoughtful usage of our Versioning policy!

General

I would like to highlight that I marked #3535 and #3538 as feat due to changes in code generation, not for functionality.

The usage of PR titles wasn't something I anticipated in the policy. Technically, they are based on a related standard Conventional Commits.
I can't speak for everyone, but I personally may have used different titles if I referred to Why Use Conventional Commits each time.
I use https://github.com/vivaxy/vscode-conventional-commits on commits and usually am just picking which description fits the closest

Is this worth opening another issue to discuss refining the policy language?

PRs to consider

• refactor: Reduce SchemaValidationError traceback length #3530
  • No public API changes, I think would be beneficial to UX but have been waiting on review for 2 weeks
• refactor: Simplify SchemaBase.copy #3543
  • No public API changes, possible perf improvements
• docs: Link to Vega Theme Test in user guide #3528
  • Easy include
• fix(typing): Resolve misc type ignores in schemapi.py #3545
  • Wouldn't say I feel strongly, but is another fix.

CI

These aren't user-facing, however there may be issues in CI with/without some/all of them:

• ci: Bump sphinx, vl-convert-python #3527
• fix(ruff): Bump ruff, fix RUF031 #3529
• ci(ruff): Enforce the default C901 complexity #3531
• ci: bump ruff>=0.6.0 #3539
• revert: Remove sphinx version constraint #3541

Possible Bugs

I'm expecting this to cause an issue for anyone running python>=3.13, originally thought it was the source of pola-rs/polars#17995 (comment):

altair/pyproject.toml

Lines 14 to 18 in 591bf40

	[project]
	name = "altair"
	authors = [{ name = "Vega-Altair Contributors" }]
	dependencies = [
	"typing_extensions>=4.10.0; python_version<\"3.13\"",

Possibly an issue, since we have typing_extensions imports outside of conditional blocks.

Fine

altair/altair/expr/__init__.py

Lines 10 to 13 in 591bf40

	if sys.version_info >= (3, 12):
	from typing import override
	else:
	from typing_extensions import override

Will raise ImportError

altair/altair/expr/core.py

Lines 3 to 4 in 591bf40

	from typing import Any, Dict, Union
	from typing_extensions import TypeAlias

Solution(s)

1. Replace the dependency with "typing_extensions>=4.10.0"
2. Rewrite all of the offending imports
3. Do nothing, as we have not declared support for python>=3.13

[joelostblom]

Thanks for the detailed response @dangotbanned!

I would like to highlight that I marked #3535 and #3538 as feat due to changes in code generation, not for functionality.

That sounds similar to my rationale in #3548 (reply in thread), so it seems reasonable to release 5.4.1 from the latest commit on main after #3550 is merged.

I use https://github.com/vivaxy/vscode-conventional-commits on commits and usually am just picking which description fits the closest... Is this worth opening another issue to discuss refining the policy language?

I think it is totally ok that we have some leeway in the interpretation of what we consider new functionality. And like you said, each commit that is a feature does not necessarily imply new functionality. I think I was a bit strict in the interpretation there; there is not necessarily a 1 to 1 mapping to the PR titles.

---

As for the Python 3.13 bugs, I think it is reasonable that we fix those once we officially declare support for 3.13.

[dangotbanned]

Sounds good to me.

For future reference, I do want to voice that I'm in favour of more frequent, smaller MINOR releases.
Even if only a small user group would benefit from the new functionality

[dangotbanned]

@joelostblom could we hold off on the patch release until these are resolved please?

• _EncodingMixin.encode types defined too narrow #3552
• fix: Resolve Then copy TypeError #3553

[dangotbanned]

Fine by me @joelostblom, I'm not in a rush so ping me if you have a deadline to meet for the docker stuff

[joelostblom]

I just checked in with your IT staff and if there is a new version up on Tue morning, then it would be good from their side. So if I can release 5.4.1 Mon night, that would be great as it takes a few hours usually to propagate to conda which is what we use in our Docker images. I think #3553 can be merged by then and even if #3552 is not ready yet (having the fixes up until now as 5.4.1 would be beneficial for our docker images, and if #3552 lands after that then altair can still follow up with 5.4.2 soon after even if that doesn't make it into our images; as you said, frequent smaller bug fixes releases are welcome)

[dangotbanned]

All good!
I'll likely put something together later today/tomorrow for #3552 if @binste doesn't beat me to it

[dangotbanned]

@joelostblom just to keep you updated, I'm thinking it might be best to hold off on resolving #3552 for now.

I proposed some alternative solutions in #3552 (comment) which I feel are more beneficial than the pragmatic one that @binste had already agreed to in #3552 (comment)

Would feel better merging one of those, but wouldn't want to push it through without approval.

Feel free to go ahead with v5.4.1 release!

[joelostblom]

Thanks for the update! I will tag e543fbc as 5.4.1 then and go ahead and create the release in a few hours.

[joelostblom]

Released, thanks everyone!

[binste]

Thanks @joelostblom 🥳

[dangotbanned]

@joelostblom @binste

Just noticed that since v5.4.1 the typing docs are showing the same as what I found in #3515 (comment)

• https://altair-viz.github.io/user_guide/api.html#typing
• https://altair-viz.github.io/user_guide/generated/typing/altair.typing.ChannelDescription.html#altair.typing.ChannelDescription
• https://altair-viz.github.io/user_guide/generated/typing/altair.typing.ChannelDetail.html#altair.typing.ChannelDetail

[joelostblom]

Is this fixed on main? (sorry on my phone and can't check right now). I was thinking of pushing an update to the docs after #3544 is merged, even if there is not a new release by then since that PR documents important functionality of 5.4.1.

[dangotbanned]

@joelostblom sort of

We settled on a temporary solution to build the docs using 3.11 - so you might be able to rebuild and get the same result as v5.4.0 that way?

I still don't fully understand why that worked.

---

FYI I'm not viewing this as an urgent problem (would have raised an issue), just wanted to note it since it wasn't what I expected to see