Remove 0.4 Deprecations #13054
Remove 0.4 Deprecations #13054
Conversation
|
b5a251b should fix the arrayops test. |
|
@jakebolewski could you clarify: these are things that were deprecated between 0.3 release and 0.4 release, and will no longer work on 0.5? Or are they things deprecrated between 0.2 and 0.3 release, and shouldn't work on 0.4? |
|
It's an interesting question. Technically, it's correct to remove 0.4 deprecations on master immediately, but in practice people might prefer a slower transition. I like to rip the bandaid right off, others like to do it slowly. |
|
I'm in Camp Bandaid FWIW, and I think doing it now is fairly principled and helps get 0.5 out that much sooner (by getting fiddly 0.4-related details). Perhaps has the social effect of keeping people well away from 0.5 too, because it'll knock out even more packages. |
|
At a minimum, it'd be nice to hold off on this until I (and/or others) get #13047 a little closer. Those doc conversions can still get backported easily. That said, some of the 0.5 changes I'd like to make will depend upon removing these deprecations. Count me in for camp bandaid. |
|
Please, rip it off! People have their 0.4 RC1 goodness already, bandaid off will make it easier to find stuff to fix in packages. |
|
Yes, my hidden intention is to force people into using the v0.4-rc right away for their primary work. @mbauman I intend to merge the doc changes before this. |
jakebolewski
force-pushed
the
jcb/rm04deps
branch
from
c146de5
to
016c81e
Compare
|
Oh, we also need to flip the |
|
Just to clarify, do the devs WANT people to use 0.5, or would they (you) prefer us to stick with 0.4? After reading the comments here I'm confused as to how I should proceed (as a non-dev). |
|
Please do not start using 0.5 immediately. |
|
If you plan on helping with developing new 0.5 features (planned or un-planned), or are happy helping test new changes that get merged, then feel free, I say. I'd say the majority of "package" developers probably don't fall in this camp, however, and need/want something more predictable to build packages against. |
|
As long as #13036 gets backported soon, I'm happy to stick with 0.4. :) Sorry for the derail and thanks for the clarification. |
jakebolewski
force-pushed
the
jcb/rm04deps
branch
2 times, most recently
from
016b1fd
to
bbe3e05
Compare
|
For crying out loud, we need to solve #11200 before doing this. Otherwise we're breaking code vindictively and without warning. |
jakebolewski
force-pushed
the
jcb/rm04deps
branch
from
bbe3e05
to
c3fd3d4
Compare
|
Ok this is done. Break what code? Standard library code? I don't see why we have to have a solution ready before moving forward during the 0.5 release cycle. Certainly before tagging a release candidate. |
|
I think we can come up with a way to deprecate bindings and backport it to 0.4, so that somewhere in the middle of the cycle 0.4 users will start seeing more warnings. |
|
No, I'm saying removing deprecations that never even gave a warning is breaking user code no matter when we do it. So we shouldn't rush this, since we have time to try to fix #11200 first and make this less painful. There's zero advantage to purposefully breaking packages and user code on 0.5 as early as possible. It'll make regression testing of codegen and package manager rewrites more annoying, as one example. |
|
We need to free up the syntax to get other changes in the pipeline. If we want to release by Feb then we realistically have a little over 4 months to make that happen. All major packages that would be prudent to backtest on already depend on Compat. The package manager rewrite (if it doesn't depend on deprecated 0.4 functionality) should just work or work with minor modifications. |
|
Has Compat been updated for all of these? I'm suggesting we do this systematically, if some deprecations need to be removed for high-priority array changes then do them first. Most of those should already be giving warnings so I'm not as opposed to removing them when needed. Removing absolutely all of the deprecations en masse, including ones that never gave warnings, just isn't needed right now. |
|
I guess my only concern is I don't see how we can meet the goals of the 0.5 release while maintaining the level of stability of the 0.4 release cycle. Vindictive is a pretty loaded word, just trying not to repeat the mistakes of the past. |
| wait(p) | ||
| catch | ||
| error("IOStream redirect failed. Child stderr was \n$(readall(fname))\n") | ||
| finnaly |
jakebolewski
force-pushed
the
jcb/rm04deps
branch
from
c3fd3d4
to
db20c76
Compare
|
Another reason I dislike doing this right away is that I intend to use PackageEvaluator results on nightly as a rough filter for backporting changes from master to release-0.4. This gets less useful over time as the branches diverge, but I plan on writing up a formal backporting policy soonish that will include "don't backport code changes before PackageEvaluator has had a chance to run with them on nightly" as a guideline (mostly relevant after 0.4.0 is out when there's not as much of a rush, but still more info there than just CI even now). Breaking a bunch of code before it's actually necessary just adds a lot of noise and makes it harder to judge whether or not other changes could cause any problems. Of course 0.5 is going to have to be unstable to accomplish anything interesting. But let's wait to break code until real changes mandate doing so, not arbitrarily as soon as we're allowed to. |
|
Here's a data point regarding #11200: ~350 packages still use the characters |
not including the deprecated syntax in the parser, ref #13054 which could be rebased
not including the deprecated syntax in the parser, ref #13054 which could be rebased
not including the deprecated syntax in the parser, ref #13054 which could be rebased
Follow up on #13052.
Two tests are failing in arrayops.jl which check the return types of
setindex!andgetindex. I commented them out for now.~~Still need to remove syntax deprecations.~~~