Release 0.12

[c42f]

There's a lot of cleanups done in the last few months thanks to many people and we need a new release. It contains a few deprecations but there's still a couple of things unresolved at #532 so this will be 0.12.0.

TODO for 0.12.0:

• Finish review of Conversion of SizedArray to Array reshapes #666
• Consider how to advertise the new SA feature vs the existing macro constructors and gather user feedback (maybe document it as experimental, and advertise on discourse).

Here's some useful release notes which were generated for 0.11.1 by tagbot but which largely don't actually apply to the 0.11.1 release:

v0.11.1 (2019-10-16)

Diff since v0.11.0

Closed issues:

• static sparse array (static sparse array #660)
• static arrays of heterogeneous types (static arrays of heterogeneous types #653)
• Type Stability of Constructor (Type Stability of Constructor #651)
• Bounds checking in dot (Bounds checking in dot #650)
• Broadcast operations resulting in Scalars fail (Broadcast operations resulting in Scalars fail #642)
• reduce(op, a::StaticArray) is ambiguous (reduce(op, a::StaticArray) is ambiguous #641)
• SArray initialization does not terminate (SArray initialization does not terminate #637)
• dot could be faster for SArrays (dot could be faster for SArrays #629)
• Deprecate ::Number +/- ::StaticArray ? (Deprecate ::Number +/- ::StaticArray ? #627)
• 2x2 complex exponential of zeros matrix is undefined (2x2 complex exponential of zeros matrix is undefined #623)
• example in docs for reinterpret not working (example in docs for reinterpret not working #621)
• New Release 0.11.0 (New Release 0.11.0 #616)
• expm is allocating (expm is allocating #578)
• SVector type signature is reversed compared to Base array constructors (SVector type signature is reversed compared to Base array constructors #577)
• Mixed static and dynamic dimensions (Mixed static and dynamic dimensions #573)
• MArray is slower than Array in reduction (MArray is slower than Array in reduction #540)
• Adding n x 0 matrices results in Union{} eltype (Adding n x 0 matrices results in Union{} eltype #528)
• Incorrect promotion behavior of MVectors? (Incorrect promotion behavior of MVectors? #516)
• Error with diagonal \ static\_row (Error with diagonal \ static_row #504)
• reinterpret of Arrays of static arrays failed (reinterpret of Arrays of static arrays failed #501)
• Mutating fields of immutables (Mutating fields of immutables #490)
• problem with StaticArrays and \ (problem with StaticArrays and \ #487)
• missing SMatrix \ Vector method (missing SMatrix \ Vector method #486)
• broadcasting of Tuples and SVectors is broken (broadcasting of Tuples and SVectors is broken #485)
• Add Vector/Matrix/Array constructors that match Base (Add Vector/Matrix/Array constructors that match Base #481)
• Type instability when all the parameters of SMatrix are not declared in a structure (Type instability when all the parameters of SMatrix are not declared in a structure #475)
• Introduce a Point type? (Introduce a Point type? #469)
• Matrix multiplication slower in 0.7 (Matrix multiplication slower in 0.7 #462)
• norm(matrix) -> opnorm(matrix) in Julia 0.7 (norm(matrix) -> opnorm(matrix) in Julia 0.7 #447)
• Use new 0.7 interface for QR and co? (Use new 0.7 interface for QR and co? #445)
• Don't commit type piracy in test/qr.jl (Don't commit type piracy in test/qr.jl #437)
• Some linalg.jl generated functions return values, not expressions, in some cases (Some linalg.jl generated functions return values, not expressions, in some cases #435)
• Error returning eltype of SMatrix (Error returning eltype of SMatrix #423)
• Type changes from MArray to SArray upon using broadcast (vectorization) (Type changes from MArray to SArray upon using broadcast (vectorization) #403)
• Getting Union eltype for length-0 array conversion (Getting Union eltype for length-0 array conversion #396)
• @svector rand and randn don't work with rng argument (@SVector rand and randn don't work with rng argument #391)
• floor, ceil, round called with (::Type{T}, ::SArray) return SArray of Any (floor, ceil, round called with (::Type{T}, ::SArray) return SArray of Any #390)
• Adding "algebraic expansions" ? (Adding "algebraic expansions" ? #351)
• ERROR: MethodError: no method matching result_style(::Type{StaticArray}) (ERROR: MethodError: no method matching result_style(::Type{StaticArray})  #347)
• work with ArrayViews (work with ArrayViews #333)
• Provide a more basic example (Provide a more basic example #304)
• show methods cause unhandled exception errors on master (show methods cause unhandled exception errors on master #283)
• Unary and binary operators on SArray do not return SArray in Julia 0.7 (Unary and binary operators on SArray do not return SArray in Julia 0.7 #272)
• Give a meaningful error message for convert\(SVector,::Vector\) or SVector\(::Vector\) (Give a meaningful error message for convert(SVector,::Vector) or SVector(::Vector) #259)
• Feature request: Allow syntax @svector 2:N-1 (Feature request: Allow syntax @SVector 2:N-1 #223)
• Return UpperTriangular from chol (Return UpperTriangular from chol #194)
• Change in subtyping for StaticVector from Julia 0.5 to 0.6 (Change in subtyping for StaticVector from Julia 0.5 to 0.6 #152)
• C error leaking into StaticArrays code (C error leaking into StaticArrays code #117)
• Automatic functionality a la FixedSizeArrays (Automatic functionality a la FixedSizeArrays #114)
• Missing convert method to facilitate initialisation of fields of type SArray (Missing convert method to facilitate initialisation of fields of type SArray #110)
• Storing tuples in StaticArrays (Storing tuples in StaticArrays #93)
• Incorrect element type with .^ after importing Gadfly (Incorrect element type with .^ after importing Gadfly #78)
• Implement LU matrix factorization (Implement LU matrix factorization #73)
• Implement Singular Value Decomposition (Implement Singular Value Decomposition #72)
• slow construction and a big memory allocation overhead (slow construction and a big memory allocation overhead #40)
• Unified, efficient code for mutable and immutable AbstractArrays (Unified, efficient code for mutable and immutable AbstractArrays #32)
• inv, det, etc. with SMatrix{2,2,T<:Unsigned} (inv, det, etc. with SMatrix{2,2,T<:Unsigned} #29)
• Allow @svector comprehension to eval range with locals? (Allow @SVector comprehension to eval range with locals? #26)
• Naming for small vectors (Naming for small vectors #24)

[c42f]

Release announcement: https://discourse.julialang.org/t/staticarrays-0-12-0-new-static-array-literal-syntax/30645

[KristofferC]

Just pointing out that this is a very popular package and releasing breaking versions will take some time to trickle down downstream. https://gist.github.com/KristofferC/7c8048e2ee9aaa465966caeb98c1446a shows how many packages upper bounds a certain package to not the latest version and in another file what packages does that. StaticArrays is the package most upper bounded of all packages (with the recenet release of 0.12).

[c42f]

Thanks @KristofferC for pointing that out. I noticed this myself to some extent when the resolver decided my local environment was inconsistent with a dev'd StaticArrays 0.12. I think this is the first time I've really seen the effect of the more reliable Pkg3 conventions in properly upper bounding dependencies.

0.12 is not very breaking, but I think there's maybe 4 or so packages which could have been affected by some deprecations so I guess everyone else is going to have to deal with bumping the upper bound :-/

Unfortunately we will need at least one more release to get to a 1.x release series (even if there's nothing breaking which is outstanding, oddly enough). I guess I should make the most of it and look carefully for some other deprecations which might be desired.

[KristofferC]

Personally I don't think a few deprecations should warrant considering the release not backwards compatible. Deprecation warnings can quite easily be fixed especially if it is just a few packages. It seems less bad than getting upper bounds from dozen of packages.

[c42f]

Well it's just not very clear cut. For many people StaticArrays performance regressions would be considered breaking changes and depwarns themselves are a massive performance regression. Julia itself considered depwarns to be breaking and left them in for one release before removing them 🤷‍♂️

Deprecation warnings can quite easily be fixed especially if it is just a few packages. It seems less bad than getting upper bounds from dozen of packages.

It's still pretty hard to get an idea of which packages those might be without some tooling for large scale testing and some infrastructure to run it on. My impression was based on some regex searching of code on pkg.julialang.org which is great as far as it goes, but only a very rough guide for these particular changes.

[timholy]

I do think suddenly receiving a bunch of deprecation warnings is worthy of a breaking-change tag. There's a growing number of Julia users who don't know how you'd go about fixing deprecations, despite the fact that a seasoned programmer would say that the depwarn tells you what to do. If you don't know how to dev the package, fire up the editor, make a git commit, and submit it, the depwarn can be effectively breaking.

Even if you do know all of these things, it would be bad if, say, I've put together a nice talk to give at a major symposium and then make the mistake of doing a package update right before giving my talk without running through the entire presentation.

[KristofferC]

Even if you do know all of these things, it would be bad if, say, I've put together a nice talk to give at a major symposium and then make the mistake of doing a package update right before giving my talk without running through the entire presentation.

Well, a) don't do that, b) backup your project.

Anyway, releasing backwards incompatible releases for popular packages will always be a pain for the ecosystem so ideally as many breaking changes as possible is bundled up into one release.

[tkoolen]

My two cents: since this package is performance-minded, any deprecation warning should be a breaking change. In fact, I have tests in one of my packages that assert that certain operations don't allocate. Those break with deprecation warnings.