This article is a work of art: Dear Google Cloud: Your Deprecation Policy is Killing You I never really thought much about this topic, but this article picqued my curiosity. Are we (Julia community) doing enough thinking about backwards compatibility? While passively observing discussions about s…

That’s what all the concern-mongering in this thread reads like :man_shrugging: Regarding multiple dispatch and deprecations, yes, for simple renames and changes to argument types, you can do deprecations pretty easily. But those are the least interesting kinds of changes for 2.0. There’s an issue …

there is always th python 2->3 saga to remind us and it more directly relevant. There was recently a PSA about Julia 2.0 I think.

[image] anon67531922: I get the impression that we are actually ok with breaking code written for v1.0 when v2.0 is released (pretty much the definition of semver), but is that really ok? I get the impression that breakages will happen only if there is no other way and the benefit justifies t…

[image] xiaodai: there is always th python 2->3 saga to remind us and it more directly relevant. There was recently a PSA about Julia 2.0 I think. Julia is setup a lot better than Python in these respects for two major reasons. One is immutability. Especially with the Pkg server, the Julia v…

In my experience the julia environment prefers moving forward and break to keeping strict backward compatiblity. The effort to adapt packages to new and breaking language features is delegated to package maintainers. Compat and tools will help, but not at 100%. A recent example for me was that the (…

[image] lobingera: A recent example for me was that the (standard) random generator is version specific - so if you run your code on 1.5 vs. 1.4 you get different numbers - which can hurt a lot in testing. Use GitHub - JuliaRandom/StableRNGs.jl: A Julia RNG with stable streams

https://github.com/rfourquet/StableRNGs.jl/issues/4

I hear you guys. I still think it should be technically possible to release v2.0 without breaking v1.0 though even if it means some redundancy (like the Android example). You can see Android’s commitment to backwards compatibility in their APIs. It’s a sure sign, when there are four or five differ…

[image] anon67531922: I still think it should be technically possible to release v2.0 without breaking v1.0 Think like this: Do you volunteer to do it?

[image] anon67531922: if any community can crack this, the amazing Julia maintainers could Possibly — but it would distract them from providing amazing new improvements to the language. Recognizing that maintainers are a finite, scarce resource, personally I would prefer if they could keep f…

[image] lobingera: Do you volunteer to do it? No. So what?

[Article] Dear Google Cloud: Your Deprecation Policy is Killing You

Internals & Design

Tamas_Papp August 16, 2020, 6:20am 3

I get the impression that breakages will happen only if there is no other way and the benefit justifies the cost. Cf

Topic		Replies	Views
Avoiding a Julia version of the Python 2/3 mess Internals & Design	22	3983	October 18, 2019
Thoughts on eventual Julia 2.0 transition Internals & Design upgrades	47	9401	October 15, 2018
Enough deprecations! Internals & Design	24	3561	August 1, 2018
Moving from v0.6 to v1.0 has been so annoying General Usage	36	3486	October 4, 2018
1.0 adoption path? General Usage	76	14498	July 21, 2018

[Article] Dear Google Cloud: Your Deprecation Policy is Killing You

Related topics