Skip to content

CompatHelper: bump compat for Makie in [weakdeps] to 0.23, (keep existing compat) #39

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

github-actions[bot]
Copy link
Contributor

This pull request changes the compat entry for the Makie package from 0.22 to 0.22, 0.23.
This keeps the compat entries for earlier versions.

Note: I have not tested your package with this new compat entry.
It is your responsibility to make sure that your package tests pass before you merge this pull request.

@thchr thchr force-pushed the compathelper/new_version/2025-06-12-01-20-57-522-00969420346 branch from 77196e9 to 3079171 Compare June 12, 2025 01:21
@kbarros
Copy link
Contributor

kbarros commented Jun 12, 2025

After going through some documentation examples, this Makie version bump looks functional to me!

@thchr, I wonder if you'd consider a less constraining [compat] entry,

Makie = ">= 0.22"

such that Brillouin doesn't block future Makie updates. There are three registered packages that depend on Brillouin:
https://juliahub.com/ui/Packages/General/Brillouin#dependents
Users of these downstream packages may wish to update Makie and may not care about BrillouinMakieExt.

Maybe in the feature the Julia package manager could become more powerful, such that a dependent package like DFTK could say "I want to depend on Brillouin, but not BrillouinMakieExt".

@thchr
Copy link
Owner

thchr commented Jun 12, 2025

Is it possible to register Brillouin.jl with that kind of "open" compat constraint? If so, I'm happy to (although it looks like the upcoming v0.24 will have some breaking changes due to the computer graph work - though I didn't check if they will affect Brillouin).

@kbarros
Copy link
Contributor

kbarros commented Jun 12, 2025

Is it possible to register Brillouin.jl with that kind of "open" compat constraint?

It's hard to find much on Google, but I suspect "yes". For example, the JuliaRegistries README seems to suggest any [compat] entry would work.

@thchr
Copy link
Owner

thchr commented Jun 12, 2025

I don't think it's allowed, cf. https://juliaregistries.github.io/RegistryCI.jl/stable/guidelines/#Upper-bounded-[compat]-entries. I'll just merge this for now then.

@thchr thchr merged commit 10bca8e into master Jun 12, 2025
14 checks passed
@thchr
Copy link
Owner

thchr commented Jun 12, 2025

Should be a new version in the registry in about 10-15 min; thanks for the reminder to merge this 👍

@thchr thchr deleted the compathelper/new_version/2025-06-12-01-20-57-522-00969420346 branch June 12, 2025 18:00
@kbarros
Copy link
Contributor

kbarros commented Jun 12, 2025

Good catch about the compat constraints. Maybe eventually there will be something like "subpackage" instead of "extension", that allows for separate compat constraints. Some discussion here: JuliaLang/julia#58051

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants