Deprecation Julep about juleps HOT 12 OPEN

It seems to me that by its nature Compat.jl needs to be versioned separately from JuliaLang/julia. Deprecations.jl could be moved though.

What I think we need is the ability to add deprecations at any time, but have them be silent by default (either by making no the default for --depwarn, or by adding a new silent deprecation mechanism). There are also two kinds of deprecations: (1) changes like renamings, that can coexist with the new version, and (2) deprecations that need to be removed to get the new behavior (e.g. changing the meaning of an existing name or syntax).

How about this: in 2.0-alpha we turn all deprecations from silent to noisy. Then we try to have a fairly long alpha, beta and RC process. In 2.0.0-final, type (2) deprecations are removed to expose the new behaviors. Type (1) deprecations remain, and are removed in 3.0-alpha. So in general:

• version N.x: add silent deprecations
• version (N+1).0-alpha: remove type 1 deprs from version (N-1), make version N deprecations noisy.
• version (N+1).0-final: remove type 2 deprs from version N

from juleps.

It seems to me people would be even more annoyed if going from 2.0 to 2.1 were breaking, instead of just 2.0 being breaking.

from juleps.

Sorry if this is a little unrelated to the question in the issue description, but on the topic of deprecations, I was wondering whether it would be a good idea to centralize the process a bit more. Currently:

1. a breaking change is made in Base. @depwarns are created and News.MD is updated.
2. somebody (else?) needs to make a corresponding change in Compat.jl
3. somebody (else?) needs to make a corresponding change in Deprecations.jl

Are people happy with this procedure? Perhaps developer overhead could be reduced by centralizing these in JuliaLang/julia.

from juleps.

I wrote that they would error in (N+1).0-alpha

from juleps.

I've often imagined doing using Julia 1.3 (or something like that) to indicate that you are following the best practices of Julia 1.3 and higher, which would warn/error on anything that was valid in 1.0-1.2 but has been replaced by something newer since then. This would have to be per-file or per-module.

from juleps.

In fact I suspect we do need a silent deprecation mechanism (which might consist only of marking things as such in the documentation), since changing the code in any way (e.g. to call depwarn or check a flag) could have overhead.

from juleps.

Here is the semver statement: https://semver.org/#how-should-i-handle-deprecating-functionality

from juleps.

That certainly seems like it should be within scope of the Julep.

from juleps.

Alternate proposal is to have deprecations in 2.0-final and then deleting the deprecations in 2.1 and adding the changed behaviors then. I know that's a bit less satisfying but we've also seen that people keep asking about names/behaviors that changed because they're skipping 0.7 and going straight to 1.0.

from juleps.

@simonbyrne your option 1 would violate "semantic versioning" principle of backwards compatibility for major releases right? Or am I misreading?

from juleps.

From #51 (comment):

• version (N+1).0-final: remove type 2 deprs from version N

This would mean that these type-2 deprs never error, as they did until now, right? Would it make sense to also have a version (N+1).0-pre-final which errors instead of exposing the new behavior?

from juleps.

Also within scope is the stability of experimental features, and the role of the Future.jl stdlib.

from juleps.