# 1.0 adoption path?

**URL:** <https://discourse.julialang.org/t/1-0-adoption-path/7922>\
**Category:** General Usage\
**Created:** [December 22, 2017, 6:19pm UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922 "2017-12-22T18:19:42Z")\
**Posts on this page:** 17\
**Page:** 4

<div class="post-metadata">

**Author:** ![RoyiAvital](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/royiavital/32/571_2.png) [@RoyiAvital](https://discourse.julialang.org/u/RoyiAvital)\
**Post date:** [February 27, 2018, 7:21pm UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/61 "2018-02-27T19:21:06Z")

</div>

I’m not sure what you meant by 8 / 9 months being faster than MATLAB as MATLAB version is released each 6 months (March and September).

I think you make sense in your writing and the efforts of the team is admirable, really.  
But I think your response doesn’t touch the essence of what @bjarthur said.

If I understood him correctly, his saying is, don’t make backward compatibility a sacred thing.  
Keep moving forward in a fast pace which makes each iteration, even if not backward compatible, to be easy to digest.

Namely, nothing is special in version 1.0, 1.x or 10.x.  
Only keep moving forward in a constant pace of releases.

I’m not sure how I feel about it (Moreover, I have no cases to feel anything as I’m not a developer of the language) but it is worth considering.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [February 27, 2018, 7:35pm UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/62 "2018-02-27T19:35:03Z")

</div>

I stand corrected. I recalled Matlab being released yearly, but I guess the “a” and “b” part of their release names implies semiannual releases.

---

<div class="post-metadata">

**Author:** ![gabrielgellner](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gabrielgellner/32/75_2.png) [@gabrielgellner](https://discourse.julialang.org/u/gabrielgellner)\
**Post date:** [March 1, 2018, 5:34pm UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/63 "2018-03-01T17:34:00Z")

</div>

Maybe a mild voice of dissent, but I find the breaking changes are starting to burn me out. I like regular releases like matlab, but I think Base vision for having less breaking changes is essential not loose more “casual” users that don’t want to have multiple versions of julia around, or have to constantly change older code.

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [March 1, 2018, 6:36pm UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/64 "2018-03-01T18:36:44Z")

</div>

I’ve just been through the process of updating a few things (notably DataFrames) to 0.7 and I have to say the process was much more painful than it was for 0.6. Some really fundamental things, in particular `Array` constructors, have changed. Of course I appreciate these changes because the Julia devs are definitely doing the right thing by trying very hard to make sure they have everything _right_ in 0.7 so as not to freeze any undesirables into 1.0, so I’m not complaining.

It’s also worth noting that it tends to be _much_ harder to create code that supports 2 different versions than it is to create code that supports just the latest version, and due to the special nature of 0.7 I expect most packages to neglect 0.6 completely, so in many cases it shouldn’t be as bad.

That said, I don’t think it’s realistic to expect changes of this magnitude to go smoothly in 2.0. After 1.0 I think serious compromises will have to be made for the sake of stability or it may harm the user community. As someone who has only ever done scientific programming and is usually happy to break things I don’t like this, but that’s just how it is.

---

<div class="post-metadata">

**Author:** ![yakir12](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yakir12/32/297_2.png) [@yakir12](https://discourse.julialang.org/u/yakir12)\
**Post date:** [March 1, 2018, 8:20pm UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/65 "2018-03-01T20:20:42Z")

</div>

> [@ExpandingMan](#):
>
> I’ve just been through the process of updating a few things (notably DataFrames) to 0.7 and I have to say the process was much more painful than it was for 0.6

Could you compile a list of todos that could help guide us others with what we need to look up for, think about, test, etc? Thanks!

---

<div class="post-metadata">

**Author:** ![ExpandingMan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/expandingman/32/866_2.png) [@ExpandingMan](https://discourse.julialang.org/u/ExpandingMan)\
**Post date:** [March 1, 2018, 9:11pm UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/66 "2018-03-01T21:11:11Z")

</div>

See my new [post](https://discourse.julialang.org/t/tips-for-updating-code-for-0-7/9427).

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [March 1, 2018, 11:43pm UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/67 "2018-03-01T23:43:27Z")

</div>

Split this topic on March 1, 2018, 11:43pm UTC

7 posts were split to a new topic: [1.0 annoyances and Matlab comparison](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433)

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [March 1, 2018, 11:33pm UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/74 "2018-03-01T23:33:35Z")

</div>

I think your position is not uncommon. We’re trying to split the difference here and if we do it right everyone will be somewhat unhappy, with half of the people thinking that we’re breaking too many things too fast and half of the people thinking the opposite.

Waiting as long as Python (for example) between making breaking changes seems rather too long. We should probably do major releases every couple of years with tooling to help ease the process (and making sure it’s possible to support each pair of adjacent major versions at the same time).

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [March 2, 2018, 12:05am UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/75 "2018-03-02T00:05:09Z")

</div>

Split this topic on March 2, 2018, 12:05am UTC

A post was merged into an existing topic: [1.0 annoyances and Matlab comparison](https://discourse.julialang.org/t/1-0-annoyances-and-matlab-comparison/9433)

---

<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:** [March 7, 2018, 9:11am UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/76 "2018-03-07T09:11:08Z")

</div>

Stefan, I agree with your description of the Python 2/3 transition. This is still a pain in the a55… In our collaboration we still depend on older software which requires Python 2 and even recent changes regarding the 2/3-compat can not make things work in our case. I am maintaining a core analysis framework and still need to take care of the Python 2 world since I need to wrap that old stuff.

> [@StefanKarpinski](#):
>
> Since this process takes some time – and the larger the ecosystem, the longer it takes – this is a deadlock unless packages can support both the old and new versions during the transition. The main lesson for Julia (and other languages) is:
> 
> Always make it possible for packages to support both the previous and next versions of a language for long enough to let the ecosystem transition.
> 
> That’s what the Compat package allows and it works quite well. Having real macros helps a great deal.

Yes, Python has such a package too, called `six` and to be honest, it caused a lot of headache in the last years. Although they try to do their best to keep up with the glue code to attach to Python 2 and Python 3, they (have to) do some fancy stuff in the background which might be irrelevant for a small rot13-project but can be crucial in high performance computing. A small update/addition in `six` and suddenly your performance tests drop by 90%, halleluja.

I hope w.r.t Julia that `Compat` does not really affect the performance of the code, since I still have this `six`-trauma and to be honest, I have not used `Compat` yet in any of my packages. Of course, most of my code is not yet relevant for the public (as it is quite project specific for now), so I simply try to keep up with the bleeding edge. I also have not looked into the `Compat` source yet to see how things are implemented…

So all in all, I just wanted to say that the HPC Python community has definitely this six-thing in mind and they may be sceptical about using `Compat` 😉

---

<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:** [March 7, 2018, 9:34am UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/77 "2018-03-07T09:34:43Z")

</div>

> [@tamasgal](#):
>
> I still have this `six`-trauma and to be honest, I have not used `Compat` yet in any of my packages

I find the experience very smooth, and did not experience any performance drop from `Compat`. Actually, I got performance _gains_ when using it for the `v0.5->v0.6` transition, since deprecation warnings are costly, but that was just gaining back what I lost 😄

---

<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:** [March 7, 2018, 9:35am UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/78 "2018-03-07T09:35:36Z")

</div>

Good to hear 😂

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [March 7, 2018, 1:12pm UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/79 "2018-03-07T13:12:43Z")

</div>

> [@tamasgal](#):
>
> A small update/addition in six and suddenly your performance tests drop by 90%, halleluja.

Python is a very different language — there can be a huge penalty to taking C library code and routing it through a pure-Python compatibility layer. Compat’s job is a lot easier.

---

<div class="post-metadata">

**Author:** ![rjplevin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rjplevin/32/3132_2.png) [@rjplevin](https://discourse.julialang.org/u/rjplevin)\
**Post date:** [March 7, 2018, 7:11pm UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/80 "2018-03-07T19:11:48Z")

</div>

> [@John\_Hearns](#):
>
> But for a debugger - how much of a barrier is that in reality?
> 
> Did Grace Murray Hopper have a debugger - apart from a flyswat and sellotape?

I’m working productively in julia without a debugger. However, based on my experience with tools like PyCharm, which has a great debugger, I am working less efficiently than I would with an equivalently good debugger. This is particularly true given that julia stack traces don’t include variable values; they show only types.

Inserting print statements like I did when programming in C in the early 1980s is not efficient. The “real programmers don’t need debuggers” argument that has surfaced in these discussions from time to time strikes me as silly. Lots of people find debuggers very useful.

Grace Murray Hopper also gave us COBOL. By the “good enough for Grace” argument, that should be the end of language development, right? ;~)

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [March 12, 2018, 12:42pm UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/82 "2018-03-12T12:42:25Z")

</div>

> [@John\_Hearns](#):
>
> But for a debugger - how much of a barrier is that in reality?

Lots of good discussion on this point [here](https://discourse.julialang.org/t/how-do-you-use-debuggers/)

---

<div class="post-metadata">

**Author:** ![Liso](https://avatars.discourse-cdn.com/v4/letter/l/898d66/32.png) [@Liso](https://discourse.julialang.org/u/Liso)\
**Post date:** [July 21, 2018, 7:25am UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/83 "2018-07-21T07:25:51Z")

</div>

I just wanted to revisit your really interesting ideas during transition from 0.6 to 0.7 and checked use of `Compat.jl` in `DataFrames.jl`.

I found this [commit](https://github.com/JuliaData/DataFrames.jl/commit/1c468d6dd6d7e090306628173d436ab66b8387f7#diff-6108c932ccdff77aea536b99a80d4a79) and it seems that backward compatibility is probably hard task for Julia too.

---

<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 21, 2018, 10:28am UTC](https://discourse.julialang.org/t/1-0-adoption-path/7922/84 "2018-07-21T10:28:19Z")

</div>

> [@Liso](#):
>
> backward compatibility is probably hard task for Julia too.

I am not sure about this, but if you mean the contrast between the advice above (use `Compat`) and the [recommendation to drop support for `v0.6`](https://discourse.julialang.org/t/ann-introducing-upgradathon-fridays/12047/3), I was wondering about that too.

I think both approaches are viable: if package authors want to support v0.6 for new features, and avoid backporting, then `Compat` is the right solution. OTOH if they don’t, then the version resolution system should take care of it.

[Previous page](https://discourse.julialang.org/t/1-0-adoption-path/7922.md?page=3)