Skip to content
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

Adjust to upcoming Base Vararg change #843

Merged
merged 1 commit into from
Oct 28, 2020

Conversation

Keno
Copy link
Contributor

@Keno Keno commented Oct 27, 2020

There's two changes here:

  1. Drop unnecessary <: in Vararg. Tuples are already covariant and this form will be deprecated.
  2. Use Base.unwrapva, rather than open coding the equivalent, since the implementation will change.

With this change, everything should work with or without JuliaLang/julia#38136.

There's two changes here:
1. Drop unnecessary `<:` in Vararg. Tuples are already covariant and this form will be deprecated.
2. Use Base.unwrapva, rather than open coding the equivalent, since the implementation will change.
@Keno
Copy link
Contributor Author

Keno commented Oct 27, 2020

@mateuszbaran @c42f @andyferris If this looks good, could I get it merged/tagged? I'd like to run PkgEval on my Base change, but of course a lot of packages depend on StaticArrays, so won't get tested without this.

@mateuszbaran
Copy link
Collaborator

I think it looks fine and can be merged. Tagging is a bit of an issue though because master currently has a few slightly breaking changes and we may need to tag a breaking release.

@fredrikekre
Copy link
Member

fredrikekre commented Oct 27, 2020

Tagging is a bit of an issue though because master currently has a few slightly breaking changes and we may need to tag a breaking release.

That means a PkgEval won't be possible soon anyway since it will take time for all the ecosystem to upgrade... What are the changes? Are they truly BREAKING or are they "technically breaking"? This will be extremely disruptive.

@KristofferC
Copy link
Contributor

Perhaps try running a PkgEval with the StaticArrays master vs the latest StaticArray release and see what the results are.

@Keno
Copy link
Contributor Author

Keno commented Oct 27, 2020

Hmm? 0.12.5 was tagged from master two days ago and is the latest commit. Am I missing something?

@Keno
Copy link
Contributor Author

Keno commented Oct 27, 2020

Oh, I see. It wasn't merged.

@Keno
Copy link
Contributor Author

Keno commented Oct 27, 2020

I'll leave it to the maintainers, but if the next release would be a while, it'd be great if we could tag an 0.12.5 that's just 0.12.4 + this commit, such that the Base PR can move forward.

@mateuszbaran
Copy link
Collaborator

That means a PkgEval won't be possible soon anyway since it will take time for all the ecosystem to upgrade... What are the changes? Are they truly BREAKING or are they "technically breaking"? This will be extremely disruptive.

Nothing truly major. I think the biggest change is #783 that slightly changed how SizedArray works (including changing what view returns for MArray and SizedArray and what parent returns for SizedArray). #819 may be a small surprise for people who use eachindex on static arrays. #814 may cause some performance regressions on Julia <1.5 because it was tuned for the new memory layout.

Given how few packages actually use SizedArray according to JuliaHub it would most likely be less disruptive to tag master as a non-breaking release. From a quick look Altro.jl. RobotDynamics.jl and TrajectoryOptimization.jl may need some patching, as well as one package maintained by me (HybridArrays.jl but I already have a patch).

@andyferris
Copy link
Member

@c42f what if we release 0.13.0 under the premise of it being a “release candidate” for 1.0.0?

@Keno
Copy link
Contributor Author

Keno commented Oct 27, 2020

If the next release won't be a patch release, then I'd still like to request a 0.12.5 as 0.12.4 + this patch, so existing tagged packages with compat upper bounds on 0.12 will pick up this change.

@andyferris
Copy link
Member

andyferris commented Oct 28, 2020

I see. Sounds like we'll have to do something, then. It's not to hard too backport a few bugfixes.

I'll leave it to the maintainers

Aww, Keno, I kinda thought you were a maintainer ;)

@andyferris andyferris merged commit e5abc2f into JuliaArrays:master Oct 28, 2020
@Keno
Copy link
Contributor Author

Keno commented Oct 28, 2020

I'm pretty sure I used to have access to this repo, but that got dropped in one of the many rounds of access reshuffle ;). That's ok though. My evil plan as always been to make this package unnecessary one day, so I'll just wait until then.

@andyferris
Copy link
Member

OK I just re-invited you. I kinda think of you as our Core maintainer :)

I also created a release-0.12 branch, with just a couple of very conservative cherry-picks.

My evil plan as always been to make this package unnecessary one day, so I'll just wait until then.

My hope and dream, too.

@andyferris
Copy link
Member

This seems to be pointing to the new branch now. I suspect this will be automatic. JuliaRegistries/General#23652

@Keno
Copy link
Contributor Author

Keno commented Oct 28, 2020

Thanks @andyferris

@c42f
Copy link
Member

c42f commented Oct 28, 2020

I also created a release-0.12 branch, with just a couple of very conservative cherry-picks.

Perfect, you beat me to it.

My evil plan as always been to make this package unnecessary one day, so I'll just wait until then.

My hope and dream, too.

Haha, yes indeed.

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.

None yet

6 participants