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

**URL:** <https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019>\
**Category:** Internals & Design\
**Tags:** compatibility\
**Created:** [August 16, 2020, 4:08am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019 "2020-08-16T04:08:26Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![anon67531922](https://avatars.discourse-cdn.com/v4/letter/a/48db29/32.png) [@anon67531922](https://discourse.julialang.org/u/anon67531922)\
**Post date:** [August 16, 2020, 4:08am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/1 "2020-08-16T04:08:26Z")

</div>

This article is a work of art:

- [Dear Google Cloud: Your Deprecation Policy is Killing You](https://medium.com/@steve.yegge/dear-google-cloud-your-deprecation-policy-is-killing-you-ee7525dc05dc)

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 semver, 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 am not entirely sure how Compat.jl works, but it looks like it is for packages to support older Julia versions, but it requires changing your code, which doesn’t seem ideal. I don’t think there is currently any expectation that code written for v1.0 will work with v2.0.

When v2.0 is released, is there some way to guarantee that code written for v1.0 will still work? Should there be? Could there be some kind of internal compat to support older code?

I wouldn’t be surprised if this conversation is already happening somewhere, so references are welcome 🙂

---

<div class="post-metadata">

**Author:** ![xiaodai](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/xiaodai/32/15937_2.png) [@xiaodai](https://discourse.julialang.org/u/xiaodai)\
**Post date:** [August 16, 2020, 4:22am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/2 "2020-08-16T04:22:44Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [August 16, 2020, 6:20am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/3 "2020-08-16T06:20:04Z")

</div>

> [@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 the cost. Cf

> [@PSA: Julia is not at that stage of development anymore](https://discourse.julialang.org/t/psa-julia-is-not-at-that-stage-of-development-anymore/44872):
>
> You heard about this brand new exciting programming language called Julia and have some suggestions for how it should work. Wonderful! We’re happy to have you here and help you learn the language and listen to your ideas! However, please be aware that “new” is a relative term. Yes, Julia is newer than, say, C, which was first created in 1972 and standardized in 1989. It is not, however, new in the sense that it is still being freely designed and changed in arbitrary ways. Julia development start…

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [August 16, 2020, 6:20am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/4 "2020-08-16T06:20:41Z")

</div>

> [@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 v1.0 world has large amounts of immutability. What happens in the Python world is that packages tend to roam pretty free, so without constantly keeping up to date you won’t have a working installation. Pip is terrifying. And it can be hard to recreate an environment of 3 years ago.

While upper bounds cause their own problems, one thing that is clear is that there are so many upper bounds in the Julia ecosystem that old things won’t move. In DifferentialEquations.jl, Julia v1.0 will should get the same installation that has been there for a few years now. It won’t have the fancy new neural PDE stuff, but hey, the ODE/SDE/etc. software is still there. When Turing.jl decides to cut compability, that doesn’t mean it will go away, it just means there will be an immutable version that is there for people to rely on essentially indefinitely, unchanged. In those regards, being able to recreate past environments is really strong in Julia, which allows developers of packages to keep moving forward even if users don’t want to, and that separation isn’t bad it’s quite good! What the article is pointing out is that Google explicitly is not allowing that, partially because infrastructure is very different from package ecosystems, but also because of a philosophical difference. The core developers of Pkg have been very clear about this immutability, and it is something that many groups rely on. So upgrade Julia and package versions at your own pace: that’s how it’s designed and it’s okay!

But secondly, because of the pre-1.0 times being hectic in a universe where the competitors were well-established, Julia had to build a lot of infrastructure to help developers to upgrade. Femtocleaner, Compat.jl, `@deprecated`, etc. I’d estimate that 90% of major version upgrades are automated. Are there still issues that can come up? Yes, they always can and they always will. But, (a) immutability means that if you need something working today, use the old version and that’s okay, and (b) the vast majority of the changes are handled by automated or semi-automated tooling provided by the core development, and are extensible in a way so that package developers also get similar tooling for their users. One of the main issues in the Python 2 → Python 3 change was the lack of such tooling: it was considered the developer’s problem to upgrade, not the language author’s problem. I think everyone on the core team feels it to be part of their duty to ensure that updating versions is as smooth as possible, even during breaking changes like v1.0, and that’s a major philosophical difference (though to finalize the Python 3 change, the philosophy in the Python world had to change too!).

Moral of the story is, there’s still a high velocity in the Julia world, but I feel pretty comfortable. The other day I picked up someone’s blog post from 2017 or 2018 and took their ODE model and it created the same plot. Things move fast and DiffEq/SciML may be moving one of the fastest, but model codes still work.

---

<div class="post-metadata">

**Author:** ![lobingera](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lobingera/32/211_2.png) [@lobingera](https://discourse.julialang.org/u/lobingera)\
**Post date:** [August 16, 2020, 6:30am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/5 "2020-08-16T06:30:40Z")

</div>

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 (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.

(and for sure you will find someone on the thread commenting that the situation is worse in language X, which is actually not helpful in solving problems in language julia).

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [August 16, 2020, 6:52am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/6 "2020-08-16T06:52:57Z")

</div>

> [@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)

---

<div class="post-metadata">

**Author:** ![lobingera](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lobingera/32/211_2.png) [@lobingera](https://discourse.julialang.org/u/lobingera)\
**Post date:** [August 16, 2020, 7:17am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/7 "2020-08-16T07:17:04Z")

</div>

[https://github.com/rfourquet/StableRNGs.jl/issues/4](https://github.com/rfourquet/StableRNGs.jl/issues/4)

---

<div class="post-metadata">

**Author:** ![anon67531922](https://avatars.discourse-cdn.com/v4/letter/a/48db29/32.png) [@anon67531922](https://discourse.julialang.org/u/anon67531922)\
**Post date:** [August 16, 2020, 7:46am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/8 "2020-08-16T07:46:45Z")

</div>

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 different coexisting subsystems for doing literally the same thing, that underlying it all is a commitment to backwards compatibility. Which in the Platforms world, is synonymous with commitment to your customers, and to your marketplace.

It would definitely be harder, but it seems like it would be worth it in the long run. I think our habit is to deprecate something in one release and then break it in the next. Couldn’t it just stay deprecated and supported forever (like the Emacs example)?

> In the Emacs world (and in many other domains, some of which we’ll explore below), when they make an API obsolete, they are basically saying: “You really shouldn’t use this approach, because even though it works, it suffers from various deficiencies which we enumerate here. But in the end it’s your call.”

Note, I’m talking about Julia itself. Not just packages.

[Edit: I think if any community can crack this, the amazing Julia maintainers could.]

---

<div class="post-metadata">

**Author:** ![lobingera](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lobingera/32/211_2.png) [@lobingera](https://discourse.julialang.org/u/lobingera)\
**Post date:** [August 16, 2020, 8:01am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/9 "2020-08-16T08:01:01Z")

</div>

> [@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?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [August 16, 2020, 8:06am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/10 "2020-08-16T08:06:52Z")

</div>

> [@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 focusing on language improvements instead of supporting deprecations _forever_. That’s a long time.

---

<div class="post-metadata">

**Author:** ![anon67531922](https://avatars.discourse-cdn.com/v4/letter/a/48db29/32.png) [@anon67531922](https://discourse.julialang.org/u/anon67531922)\
**Post date:** [August 16, 2020, 8:08am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/11 "2020-08-16T08:08:03Z")

</div>

> [@lobingera](#):
>
> Do you volunteer to do it?

No. So what?

---

<div class="post-metadata">

**Author:** ![anon67531922](https://avatars.discourse-cdn.com/v4/letter/a/48db29/32.png) [@anon67531922](https://discourse.julialang.org/u/anon67531922)\
**Post date:** [August 16, 2020, 8:15am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/12 "2020-08-16T08:15:02Z")

</div>

> [@Tamas\_Papp](#):
>
> Recognizing that maintainers are a finite, scarce resource, personally I would prefer if they could keep focusing on language improvements instead of supporting deprecations _forever_ . That’s a long time.

Sure. And that would be a totally reasonable thing to do. I just keep thinking about the word “greedy” and what that means and could it be extended to a greedy commitment to backward compatibility with all the long-term benefits and goodwill that comes with that.

---

<div class="post-metadata">

**Author:** ![rfourquet](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rfourquet/32/3610_2.png) [@rfourquet](https://discourse.julialang.org/u/rfourquet)\
**Post date:** [August 16, 2020, 8:29am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/13 "2020-08-16T08:29:44Z")

</div>

Note that this issue stems from a misunderstanding of the `Random` API, `StableRNG` is still stable so far.

---

<div class="post-metadata">

**Author:** ![anon67531922](https://avatars.discourse-cdn.com/v4/letter/a/48db29/32.png) [@anon67531922](https://discourse.julialang.org/u/anon67531922)\
**Post date:** [August 16, 2020, 8:39am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/14 "2020-08-16T08:39:10Z")

</div>

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 change without deprecating it first. So why can’t we just leave it deprecated (rather than removing deprecated methods) for backward compatibility? For v0.6 to v1.0 it made sense, but maybe we could do something different for v1.0 to v2.0.

---

<div class="post-metadata">

**Author:** ![tamasgal](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamasgal/32/27946_2.png) [@tamasgal](https://discourse.julialang.org/u/tamasgal)\
**Post date:** [August 16, 2020, 8:42am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/15 "2020-08-16T08:42:27Z")

</div>

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 the problem that I still have to possibly rewrite code in order to run under Julia 2.0 but at least I can run it. I think that nowadays with Docker and other containerisation solutions, we are in a much better position than in past days where you had either nothing or slow VM solutions.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [August 16, 2020, 9:01am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/16 "2020-08-16T09:01:58Z")

</div>

> [@anon67531922](#):
>
> > [@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?

---

<div class="post-metadata">

**Author:** ![anon67531922](https://avatars.discourse-cdn.com/v4/letter/a/48db29/32.png) [@anon67531922](https://discourse.julialang.org/u/anon67531922)\
**Post date:** [August 16, 2020, 9:10am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/17 "2020-08-16T09:10:57Z")

</div>

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 devs, I would be surprised if it isn’t discussed somewhere already. I never really thought about it and went along with the semver mantra of “deprecate, then break”, but the article had me wondering if we can do better for v2.0. That is all.

---

<div class="post-metadata">

**Author:** ![oheil](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oheil/32/220745_2.png) [@oheil](https://discourse.julialang.org/u/oheil)\
**Post date:** [August 16, 2020, 9:32am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/18 "2020-08-16T09:32:23Z")

</div>

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.  
Now imagine a new user who just has to use some number of packages: o my god, what is this? The terminal is full of warnings? Not very trusting.

A second point: I am sure, having all things backwards compatible will be quite costly in terms of performance and memory usage. Just not optimal.

On the other side: making everything optimal as soon as it appears would be very breaking. Not a good idea, it would limit or stop creativity of users/developers.

So, the conclusion is clear: find a reasonable compromise of how long to keep things stable and when to break old stuff.

Now: are the Julia developers doing this compromise well and right for me? It doesn’t matter, because I still have some production code running within Julia 0.3 and it is just working perfect and self contained.

---

<div class="post-metadata">

**Author:** ![thofma](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/thofma/32/1691_2.png) [@thofma](https://discourse.julialang.org/u/thofma)\
**Post date:** [August 16, 2020, 9:37am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/19 "2020-08-16T09:37:44Z")

</div>

Very related: [Thoughts on eventual Julia 2.0 transition](https://discourse.julialang.org/t/thoughts-on-eventual-julia-2-0-transition/15756)

---

<div class="post-metadata">

**Author:** ![simeonschaub](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/simeonschaub/32/216566_2.png) [@simeonschaub](https://discourse.julialang.org/u/simeonschaub)\
**Post date:** [August 16, 2020, 9:46am UTC](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019/20 "2020-08-16T09:46:56Z")

</div>

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 some breaking changes that perhaps were missed in 1.0 and that can’t be introduced in non-breaking ways. That of course doesn’t mean that 2.0 will just break stuff at random, I think the bar will be pretty high for breaking changes. It also looks like 2.0 is still a few years off, since 1.x currently serves us quite well, but there are some smallish breaking features I’d really like to eventually see in 2.0.

[Next page](https://discourse.julialang.org/t/article-dear-google-cloud-your-deprecation-policy-is-killing-you/45019.md?page=2)