-
Notifications
You must be signed in to change notification settings - Fork 153
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
Release 1.0.0 #532
Comments
Presumably the FixedSizedArrays compatibility layer can also be removed? |
Yes, it is deprecated and was vendorised in the only dependence: JuliaGeometry/GeometryTypes.jl#153 |
Good idea, see #600. |
Will release v1.0.0 have any breaking changes? |
Probably a few more deprecations to come during cleanup but nothing specifically on my mind. Currently it seems that bumping major versions of widely used packages is a bit more disruptive than would be ideal, so it would seem best to wait until we have a batch of breaking changes. There's no plan for a major rewrite or large change in the APIs though; it's mostly incremental maintenance at this stage. |
Just wanted to say thanks for all the effort you've put into the package lately, @c42f! |
Thanks Twan, I'm slowly chipping away at cleaning a few dark corners of the implementation :-) |
Could we have #783 in 1.0? |
Yes indeed 👍 |
What's the 1.0 timeline? |
No specific timeline. Releasing major versions is kinda disruptive so I wanted to make the 0.12 -> 1.0 transition "worthwhile" in that it cleaned up a few things at once. But resolving all of the big list of "desirable issues" above is more than I can bite off at the moment, so at this point I think it might be best just to make 1.0 the next major release (in the near future) and deal with the thorny problem of Looking back at the list of issues at the top of this thread, most of them are more desirable than necessary for 1.0 anyway, as many are bug fixes and other things which aren't breaking. What do you think @andyferris? |
We should clean up the macros a bit, probably. I see what you mean by a lot being desirables. Honestly - a fundamental change like a really good treatment of axes/keys might warrant a future 2.0 release if it turns out to break dependent packages. Basically I’m in on your plan, @c42f. |
Agreed it would be nice to clean up the macros somewhat, maybe deprecating a little questionable functionality if there's any left. My general thoughts about the macros are that we're still not in a position to deprecate them soon because we haven't landed on a satisfying solution for things like |
Well, @tkf just reminded me about StaticNumbers.jl; I suppose the "correct" solution in some sense would be |
I was jus writing "Why not Alternatively, maybe we can use |
Actually this already works. But I've never felt really happy that it's semantically compatible with Base so I don't think it's a replacement. |
Oops, I should've checked if it works before posting it. But why it's not a replacement? I think it'd be nice if you can get a random data structure with a generic API like |
Sure, it's fine in that sense, and it's quite compatible in meaning with things like |
I don't think shooting for Having said that, it may be reasonable for |
Are there any changes needed for 1.0? Or could we have it released? |
I think if you need it, it's probably best to release it. Obviously I'd like to have time to fix more things and carefully assess the state of it ;-) But I don't have it, and I can't see anything really blocking holding us up. |
I don't strictly need it, I'd just like to make some cleanup in HybridArrays.jl and Manifolds.jl that depends on |
Sounds like you need it to me! Let's release. |
Yay! So, our work here is done, right? :) |
Thanks! I hope there won't be too many problems across the ecosystem 🙂 . |
As discussed over at #522, it's almost time for a 1.0.0 release. Personally I think there should be no great breaking changes here and we should try to make it compatible with the status quo of the last year or so. However, we can take the opportunity to make it as consistent with the final state of julia-1.0 Base as possible via a few targeted deprecations (with proper depwarns).
Here's a TODO list (moved from prior discussion at #522). Feel free to add or suggest items.
SDiagonal
in favor ofBase.Diagonal
Replace SDiagonal with LinearAlgebra.Diagonal of SVector #531@SA
macro and comprehension support #636)Deprecate (most of?) the zoo of constructor macros (replace with WIP/RFC: Implement SA[...] syntax for SArray literals #633 ?) but keep them around in the 1.0 release cycle.Can be soft-deprecated laterConstructors with generators or ntuple like syntax Constructing StaticArrays with generators or ntuple-like syntax #97Can be done laterRevisitToo big for 1.0axes
;SUnitRange
etc to consider whether these design changes should go into 1.0Tidy up usage ofSOneTo
(follow up of AddSOneTo
asAbstractUnitRange
to representaxes(::StaticArray)
#534; see also export & document SUnitRange #620)Export ofSUnitRange
export SUnitRange #474Consider modernizing & merging WIP ReturnSUnitRange
fromindices(::StaticArray)
#150Union{}
) cf. Adding n x 0 matrices results in Union{} eltype #528MArray
s #327The text was updated successfully, but these errors were encountered: