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 …

If I think back to the v1.0 release and we went from v0.6 to v0.7. The v0.7 was basically the v1.0 release, but with deprecations to give people a chance to update their packages. The v1.0 was the same as the v0.7 release except those deprecations became errors. We would never introduce a breaking c…

I’d like to emphasise that there is also a crucial difference between an online service and an offline software. I cannot roll back the Google Cloud API to an old version as an end-user, but I can recreate an environment with Julia 1.0 and all the dependencies easily. That of course does not solve …

[image] anon67531922: [image] lobingera: Do you volunteer to do it? No. So what? You just put an upper bound on the ostensible benefits — they are not worth your time. Why would they be worth someone else’s, if you are one of the people who cares about this issue?

Of course, I will help if I can. I didn’t find that comment particularly helpful (and flagged it actually) and should have just ignored it. It is with good intentions I bring this up. I think v2.0 is still far enough away that it makes sense to have this conversation. Like I said, knowing the Julia…

Let things deprecated without erroring out will be at some time point in future very annoying and frustrating. Package maintainers could postponing needed updates to their package, because it still works. Maybe deprecation warnings can be switched off? Even worse: no need at all to update a package. …

Maybe I am misunderstanding something here, but what you propose here for 2.0 sounds to me like it could just be called a 1.x release. Deprecations aren’t possible for every feature, especially when it’s changes in the parser or bigger language features. The point of a 2.0 release would be to make s…

[image] thofma: Very related: Thoughts on eventual Julia 2.0 transition Thanks :+1: [image] oheil: Let things deprecated without erroring out will be at some time point in future very annoying and frustrating. Package maintainers could postponing needed updates to their package, because…

[image] anon67531922: I didn’t find that comment particularly helpful (and flagged it actually) The comment is about trying to see this problem from a different perspective. I’m very much in favour of backward compatibility and in the SW project i run, we’re providing backward compatiblity to…

[image] lobingera: The comment is about trying to see this problem from a different perspective. Thanks for clarifying :+1: [image] lobingera: Out of my experience this x is rather a two-digit number and you are really lucky if the first digit is 2. You could be right that x > 30%, bu…

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

Internals & Design

thofma August 16, 2020, 9:37am 19

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

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

Related topics