ConstructionBase.jl
ConstructionBase.jl copied to clipboard
next steps
Release
- [x] Tag a release
- [ ] announce on discourse
Propagate through ecosystem
- [x] Setfield.jl, see https://github.com/jw3126/Setfield.jl/pull/91
- [x] Kaleido.jl, see https://github.com/tkf/Kaleido.jl/pull/8
- [x] https://github.com/tkf/BangBang.jl/pull/21
- [x] Flatten.jl
- [x] QuickTypes.jl, see https://github.com/cstjean/QuickTypes.jl/pull/14
- [ ] Parameters.jl, see https://github.com/mauro3/Parameters.jl/pull/105
- [ ] DiffEqBase.jl
- [x] FieldDefaults.jl
- [x] DynamicGrids.jl
- [x] Unitful.jl
Feel free to edit this list @tkf @rafaqz
Thanks for organising this, unfortunately I'm too busy with travel and deadlines for my modelling packages to help much.
But I'll update all my own packages when this is in metadata.
Maybe we can release 1.0 sometime soon? Maybe after bringing this up in discourse so that we can get some more feedbacks? I think setproperties and constructorof are pretty solid and already 1.0-ready. Things like setproperties!! #25 can be released with a note saying that it's experimental even after 1.0.
This came up in https://github.com/queryverse/ElectronDisplay.jl/pull/35
I am okay with release 1.0.
I'm wondering about the version as well, especially given packages are putting upper bounds on everything for auto-registration. My pull-request for Unitful.jl needs an upper bounds before it can be merged, and other packages will too. Moving to 1.0 will break that... what should our strategy be here?
Edit: I agree releasing 1.0 is reasonable now, especially as full semvar gives more confidence for a package that should be a core dep everywhere, and really wont be changing its inteface.
I think we can just release 1.0 as is and add ConstructionBase="1" to [compat] sections of PRs.