# Enough deprecations!

**URL:** https://discourse.julialang.org/t/enough-deprecations/12721
**Category:** Internals & Design
**Created:** [July 29, 2018, 9:05am UTC](https://discourse.julialang.org/t/enough-deprecations/12721 "2018-07-29T09:05:05Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)
#### Post date: [July 29, 2018, 9:05am UTC](https://discourse.julialang.org/t/enough-deprecations/12721/1 "2018-07-29T09:05:05Z")

</div>

Why are we even considering adding new deprecations like [Rename srand to Random.seed! by MoonCoral · Pull Request #28295 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/28295) on the eve of rc1, weeks into the upgradathon and long after the beta release which explicitly said “now is a good time to get your packages ready for 0.7”? There’s something fundamentally wrong with the timing of this.

---

<div class="post-metadata">

### Author: ![swissr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/swissr/32/208_2.png) [@swissr](https://discourse.julialang.org/u/swissr)
#### Post date: [July 29, 2018, 9:35am UTC](https://discourse.julialang.org/t/enough-deprecations/12721/2 "2018-07-29T09:35:43Z")

</div>

You have a point of course. But I much prefer if such occasional last-minute changes will be done still. After 1.0 it’s too late.

Also such a small syntax change (srand → Random.seed!) doesn’t seem problematic, one commit and your package is up-to-date again, no?

---

<div class="post-metadata">

### Author: ![fredrikekre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fredrikekre/32/1688_2.png) [@fredrikekre](https://discourse.julialang.org/u/fredrikekre)
#### Post date: [July 29, 2018, 10:26am UTC](https://discourse.julialang.org/t/enough-deprecations/12721/3 "2018-07-29T10:26:28Z")

</div>

> [@swissr](#):
>
> Also such a small syntax change (srand -\> Random.seed!) doesn’t seem problematic, one commit and your package is up-to-date again, no?

Indeed, seems like an easy find and replace. There is even [a bot](https://github.com/JuliaComputing/FemtoCleaner.jl) that will do it for you!

---

<div class="post-metadata">

### Author: ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)
#### Post date: [July 29, 2018, 10:30am UTC](https://discourse.julialang.org/t/enough-deprecations/12721/4 "2018-07-29T10:30:03Z")

</div>

For your own package maybe. If you try to get your dependencies upgraded it involves other people finding time to review, commit, and release as well. As a case in point it took 17 days to guide a 0.7 compatible Libz into METADATA. After the `srand` rename it will keep working cleanly, but it will give a deprecation warning when running its tests and fail running its own tests once the deprecation is removed.

I’m not comfortable wasting other people’s time hunting a moving target. I will keep upgrading my own code as things change but fixing other packages will have to wait until final 0.7 is released.

---

<div class="post-metadata">

### Author: ![tkoolen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkoolen/32/1603_2.png) [@tkoolen](https://discourse.julialang.org/u/tkoolen)
#### Post date: [July 29, 2018, 12:35pm UTC](https://discourse.julialang.org/t/enough-deprecations/12721/5 "2018-07-29T12:35:47Z")

</div>

It does get a bit tedious when it’s not just one package but 20, and @GunnarFarneback makes good points regarding other people’s packages. I’m hoping the depwarns for this one will be mostly confined to test code though.

---

<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: [July 29, 2018, 5:50pm UTC](https://discourse.julialang.org/t/enough-deprecations/12721/6 "2018-07-29T17:50:23Z")

</div>

> [@swissr](#):
>
> But I much prefer if such occasional last-minute changes will be done still. After 1.0 it’s too late.

I am not sure about this, I hope there will be a 2.0 in the medium run.

While I appreciate the continuing improvements on `master`, I am concerned that the “last chance to fix things” mindset will either delay the release, or result in changes that get less testing than usual.

---

<div class="post-metadata">

### Author: ![swissr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/swissr/32/208_2.png) [@swissr](https://discourse.julialang.org/u/swissr)
#### Post date: [July 29, 2018, 6:26pm UTC](https://discourse.julialang.org/t/enough-deprecations/12721/7 "2018-07-29T18:26:39Z")

</div>

I am not sure either. But I suppose it is much more difficult to change a simple name as e.g. `srand` if everybody is being used to it. Maybe I’m naïve, but such simple commands I somehow expect to be stable after 1.0.

Kind of a dilemma: beta ‘promises’ (?) no more changes but reasonably important issues still surface.

---

<div class="post-metadata">

### Author: ![NaOH](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/naoh/32/5632_2.png) [@NaOH](https://discourse.julialang.org/u/NaOH)
#### Post date: [July 29, 2018, 6:55pm UTC](https://discourse.julialang.org/t/enough-deprecations/12721/8 "2018-07-29T18:55:23Z")

</div>

> [@Tamas\_Papp](#):
>
> I am concerned that the “last chance to fix things” mindset will either delay the release, or result in changes that get less testing than usual.

The release is already delayed, proper testing would mean more delay, at this point I don’t think time matters anymore.

In the future Julia needs agile releases, shorter release cycles, at some point devs have to let a release go, as is, freeze → stabilize, and then reiterate.

> [@swissr](#):
>
> Kind of a dilemma: beta ‘promises’ (?) no more changes but reasonably important issues still surface.

That is just a misunderstanding, no one has made any promise about user facing stability, I also had the wrong expectations.

RCs are for when devs think it is finally ready (but still there won’t be any promise about no more breakage, if it’s in the name of stability, at that point neither).

So if you want a guarantee, wait for 1.x, breaking the stability promise at that point, would be outrageous, even if our definitions of stability are not the same, I don’t think anyone would dare to do that.

---

<div class="post-metadata">

### Author: ![dlfivefifty](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlfivefifty/32/1959_2.png) [@dlfivefifty](https://discourse.julialang.org/u/dlfivefifty)
#### Post date: [July 29, 2018, 7:07pm UTC](https://discourse.julialang.org/t/enough-deprecations/12721/9 "2018-07-29T19:07:54Z")

</div>

> [@NaOH](#):
>
> 1.x, breaking the stability promise at that point,

I’m under the impression that the stability promise _only_ applies to Base: StdLib may have breaking changes. It looks like this change is in StdLib anyways…

---

<div class="post-metadata">

### Author: ![NaOH](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/naoh/32/5632_2.png) [@NaOH](https://discourse.julialang.org/u/NaOH)
#### Post date: [July 29, 2018, 7:23pm UTC](https://discourse.julialang.org/t/enough-deprecations/12721/10 "2018-07-29T19:23:03Z")

</div>

Yes, you are right about that, this is only taking Base into account. So, do expect long release cycles and major breakage in the future, up til RCs (where you can expect minor breakage from then on) in all related release processes, and finally stability on point releases only.

The good thing is that release process is so long that we may at least have a long and stable Base for a while. 🙂

---

<div class="post-metadata">

### Author: ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)
#### Post date: [July 30, 2018, 12:40am UTC](https://discourse.julialang.org/t/enough-deprecations/12721/11 "2018-07-30T00:40:50Z")

</div>

While I appreciate what you are getting at.

The eve of RC1, is still the _eve_ of RC1. As in it is before RC1.  
the very reason beta2 was released and not RC1, was because it was not ready for RC – people didn’t have the confidence that nothing like this would be needed.

The time in which we stop – RC1, is the time in which we stop.

This is a bit of a tautology

---

<div class="post-metadata">

### Author: ![dlfivefifty](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlfivefifty/32/1959_2.png) [@dlfivefifty](https://discourse.julialang.org/u/dlfivefifty)
#### Post date: [July 30, 2018, 7:21pm UTC](https://discourse.julialang.org/t/enough-deprecations/12721/12 "2018-07-30T19:21:16Z")

</div>

I believe there were still new depreciations in 0.6-rc3, so even rc1 is not necessarily the end of breaking changes.

Beta software is beta software, doubly so if it’s 0.x-beta. I think by using beta software one is implicitly accepting that things might change. So it’s a bit odd to me that people voluntarily use beta software, then complain things are changed.

---

<div class="post-metadata">

### Author: ![chakravala](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chakravala/32/6832_2.png) [@chakravala](https://discourse.julialang.org/u/chakravala)
#### Post date: [July 30, 2018, 9:50pm UTC](https://discourse.julialang.org/t/enough-deprecations/12721/13 "2018-07-30T21:50:57Z")

</div>

Wasn’it planned from the beginning that breaking changes will be had before the final 1.0 release? Things are just as they are intendended to be, and then they will be stable after. Seems like a good thing to me.

---

<div class="post-metadata">

### Author: ![NaOH](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/naoh/32/5632_2.png) [@NaOH](https://discourse.julialang.org/u/NaOH)
#### Post date: [July 31, 2018, 5:15am UTC](https://discourse.julialang.org/t/enough-deprecations/12721/14 "2018-07-31T05:15:58Z")

</div>

> Wasn’it planned from the beginning that breaking changes will be had before the final 1.0 release?

No, it was planned that breaking changes caused by new features would’ve been had before the feature freeze, which was a while ago.

> Things are just as they are intendended to be,

No, if they were, Julia 1.0 would have been out some months ago.

> and then they will be stable after.

And when would you plan to spend time making sure they are stable? After the release?

How could you make sure if even on RCs there can be new breaking changes caused by new features (however small they may be), not caused just by bug fixes?

> Seems like a good thing to me.

Seems bad to me, I expect lots of quick fixes during 1.x “stable” release, all the new breaking features, should have targeted 2.x.

If there are any bugs, and their fixes are breaking we will have to live with those bugs until 2.x

I mean, it’s not the end of the world, and 1.0 will go out with more and better implemented features (not properly tested by the community ecosystem as a whole), so I can understand why some developers and users are getting tired of it.

* * *

Dev → Freeze → Alpha → Beta → RCs → Release → Reiterate

In order to get from “free” development to a stable release, a stabilization period is needed in each release cycle.

This period is divided in many sub-phases (as much as needed), with the sole purpose of each next phase being more stable (feature wise) than the last one.

This stabilization is started by a feature freeze, after which, **only** bug fixes should be allowed, some fixes may cause breaking API changes, but still, any new features (specially the breaking ones) should continue being developed in development branches (for the next release (2.x)).

In this sense the Julia release cycle, even when meaning to use the same terminology and bending their semantics, is very atypical, sometimes very rushed, sometimes too lax, with little communication to users outside of core dev circles, and I’ll timing of announcements vs decisions.

I am not ungrateful, I really admire the work done on Julia and the devs.

I hope we can all learn of this first major release cycle, to time and communicate intentions better, and have more discipline in self imposed dead lines like feature freezes.

Yet I can not agree that things are just as they were intended to be, unless you think the 1.0 feature freeze and the 1.0 release will be the same event (because new features even if non breaking at RCs time means there is still not a proper feature freeze).

That being said I truly believe time doesn’t matter anymore, just take your time, to test everything properly, I hope many many RCs are released along the way, and that the last one won’t introduce any last minute minor breaking or non breaking features at all, just bug fixes.

Give people time to adapt, don’t play with their efforts and expectations, those are worth too! If you make any wrong decisions or announcements, learn to retract them (not apologize), don’t just go on with it and pretend it’s normal.

---

<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: [July 31, 2018, 5:58am UTC](https://discourse.julialang.org/t/enough-deprecations/12721/15 "2018-07-31T05:58:25Z")

</div>

> [@chakravala](#):
>
> Things are just as they are intendended to be

cf

> [@1.0 Feature Freeze Dec 15th](https://discourse.julialang.org/t/1-0-feature-freeze-dec-15th/7209):
>
> It’s getting real, folks! 0.7/1.0 feature freeze has been set for Dec 15, 2017 AoE (“[Anywhere on Earth](https://www.timeanddate.com/time/zones/aoe)” time). That means that if there’s a feature you want in 1.0 it needs to be in by then or it’ll have to wait for 1.x (or 2.0 if it’s breaking). The current list of issues that are considered blocking can be found on the [milestone overview](https://github.com/JuliaLang/julia/milestone/4). However, since the feature freeze is approaching we’ll be increasingly aggressive about kicking things off the milestone that can be done in a non-breaking f…

In retrospect, I wonder if a v0.8 would have made sense before v1.0.

---

<div class="post-metadata">

### Author: ![chakravala](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chakravala/32/6832_2.png) [@chakravala](https://discourse.julialang.org/u/chakravala)
#### Post date: [July 31, 2018, 6:21am UTC](https://discourse.julialang.org/t/enough-deprecations/12721/16 "2018-07-31T06:21:26Z")

</div>

As far as I’m concerned, things are exactly as they are intended to be, with time and patience everything will fall into place. It is restlessness and agitation that is going to lead to shoddy results due to pre-mature decision points. In the grand scheme of things, a few minor deprecations are going to be forgotten, at least from my point of view. I’m happy there are people out there committed to finding issues and fixing them and getting it fixed for everyone. If there are a few more changes, it is a sign that there is productive activity happening, meaning that things are getting better. These are the intentions that I stand by, this is open source, so somebody is bound to be dissappointed, but I’m happy.

---

<div class="post-metadata">

### Author: ![NaOH](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/naoh/32/5632_2.png) [@NaOH](https://discourse.julialang.org/u/NaOH)
#### Post date: [July 31, 2018, 7:21am UTC](https://discourse.julialang.org/t/enough-deprecations/12721/17 "2018-07-31T07:21:08Z")

</div>

We’ll just have to agree to disagree. Things are exactly as they are, not as they were intended to be.

You say “a few more minor deprecations/changes”, I wonder how much more can still be considered “a few”. Also these minor changes add up!

For the release to happen, we need to stop making changes for that target at some point.

But I am glad you are happy! 🙂

---

<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: [July 31, 2018, 7:21am UTC](https://discourse.julialang.org/t/enough-deprecations/12721/18 "2018-07-31T07:21:17Z")

</div>

> [@chakravala](#):
>
> restlessness and agitation

With respect, I don’t perceive either in the community. Just some confusion about whether v0.7 is still a moving target. I welcome the improvements, but I also recognize the fact that some package developers would time their work on updates accordingly.

My reading of the v0.7 release cycle is the following:

1. For the language _per se_, v0.7 introduced truly fantastic features and compiler optimizations, and laid the groundwork for others. This allows a convenient redesign of some interfaces, which will probably be going on for a while.

2. In parallel, Pkg3 is coming. This, again is an important and very significant change for the package ecosystem.

3. It is mostly the same people are working on many of these things, which strains scarce resources.

---

<div class="post-metadata">

### Author: ![tpoisot](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tpoisot/32/19812_2.png) [@tpoisot](https://discourse.julialang.org/u/tpoisot)
#### Post date: [July 31, 2018, 5:04pm UTC](https://discourse.julialang.org/t/enough-deprecations/12721/19 "2018-07-31T17:04:14Z")

</div>

> [@Tamas\_Papp](#):
>
> v0.8 would have made sense before v1.0.

I don’t think it would have been a good thing. I’m happy to see some more changes before 0.7 (especially this one, which makes tons of sense). A few more weeks are always going to be worth it if means a “better” 1.0.

More broadly, the upwards trajectory of _everything_ in the language (looking back from 0.3) means that we can trust the core devs. I think the track record here speaks for itself.

---

<div class="post-metadata">

### Author: ![vvjn](https://avatars.discourse-cdn.com/v4/letter/v/5f9b8f/32.png) [@vvjn](https://discourse.julialang.org/u/vvjn)
#### Post date: [August 1, 2018, 2:31am UTC](https://discourse.julialang.org/t/enough-deprecations/12721/20 "2018-08-01T02:31:36Z")

</div>

> [@tpoisot](#):
>
> More broadly, the upwards trajectory of _everything_ in the language (looking back from 0.3) means that we can trust the core devs. I think the track record here speaks for itself.

I feel like that logical fallacy should have a name. If I trusted the upward trajectory of a company I would be super rich right now.

Regarding deprecations, I feel like the core team did a huge cop out when they decided to split off the standard library from base, and then guarantee no stability in the standard library. I was promised a stable julia base for 1.0 only to find out now that the stable julia base is now a small fraction of what was promised.

[Next page](https://discourse.julialang.org/t/enough-deprecations/12721.md?page=2)
