# Julia's Release Process

**URL:** <https://discourse.julialang.org/t/julias-release-process/28122>\
**Category:** Internals & Design\
**Created:** [August 28, 2019, 4:58pm UTC](https://discourse.julialang.org/t/julias-release-process/28122 "2019-08-28T16:58:10Z")\
**Posts on this page:** 20\
**Page:** 1

<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:** [August 28, 2019, 4:58pm UTC](https://discourse.julialang.org/t/julias-release-process/28122/1 "2019-08-28T16:58:10Z")

</div>

I wrote a blog post explaining Julia’s release process, collecting information from various places:

> **[Julia’s Release Process](https://julialang.org/blog/2019/08/release-process/)**
>
> Julia’s Release Process | People involved in the day-to-day development of a project tend to become so familiar with its rhythm and process that they internalize it and it feels like everyone must just \_know\_ how each stage unfolds. Of course, from...

Also being discussed on Hacker News right now if anyone cares to join that conversation.

---

<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 28, 2019, 6:14pm UTC](https://discourse.julialang.org/t/julias-release-process/28122/2 "2019-08-28T18:14:42Z")

</div>

Thanks for making a blog post about this.

I am wondering if at some point there could be some community consensus or advice about packages depending on a minimum specific (minor) version of Julia. Applicable scenarios include

1. relying on something specific that that was introduced in 1.x and just makes life easier and may not be available even in Compat.jl,

2. performance/inference problems with earlier versions, but with code running correctly for all of 1.\*

I think this is relevant because if at some point commonly used packages start depending 1.1 or 1.2 etc, users using 1.0.\* will just have to make a choice between upgrading Julia or not getting improvements/bugfixes for some packages.

---

<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 28, 2019, 7:37pm UTC](https://discourse.julialang.org/t/julias-release-process/28122/3 "2019-08-28T19:37:53Z")

</div>

Very well written and very informative! Thank you.

> [@Tamas\_Papp](#):
>
> I think this is relevant because if at some point commonly used packages start depending 1.1 or 1.2 etc, users using 1.0.\* will just have to make a choice between upgrading Julia or not getting improvements/bugfixes for some packages.

And this scenario is what I during the last years constantly was being confronted in my R environment. It is even more drastically because I am repeatedly forced to upgrade the R version for a specific package which must be used in a specific minimum version and another must-have-package forbids the upgrade = deadlock, with various bad and errorprone not-solutions (workarounds).

Currently there is no Julia strategy to avoid similar deadlocks in future and I have no good solution. Julia and its package environment is community driven and thats what comes with it.

The big advantage, which let me don’t loose faith, is, that a Julia package is written in Julia and not C. Typically.

---

<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:** [August 28, 2019, 7:47pm UTC](https://discourse.julialang.org/t/julias-release-process/28122/4 "2019-08-28T19:47:13Z")

</div>

Julia tends to be a lot easier to write code that supports a range of incompatible versions in. Compat is of course the ultimate version of that, but it can be done in a more one-off fashion as well. I think we’ll have to collectively figure this out as it becomes an issue. It’s a bit too early in the lifetime of the language to discourage people from using new features in new versions. I hope that all our diligence with making upgrades truly non-breaking will pay off by encouraging people to upgrade regularly without fear.

---

<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 28, 2019, 7:57pm UTC](https://discourse.julialang.org/t/julias-release-process/28122/5 "2019-08-28T19:57:07Z")

</div>

> [@StefanKarpinski](#):
>
> It’s a bit too early in the lifetime of the language to discourage people from using new features in new versions.

Hopefully it was not me who sounds discouraging, but I am afraid that I was, so let me say, just in case, the opposite is the case, it is not only that I do not loose faith, the truth is, that I am quite sure, that even if I run into version deadlocks in future, I will be able to solve these issues in a much better way than it is feasible in R. Solutions which are really solutions and not only workarounds.  
And even now I am inexact, because R itself is a minor problem, it is bioconductor which is the main source of headaches. But take this just as a side note.

---

<div class="post-metadata">

**Author:** ![non-Jedi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/non-jedi/32/3645_2.png) [@non-Jedi](https://discourse.julialang.org/u/non-Jedi)\
**Post date:** [August 29, 2019, 1:20am UTC](https://discourse.julialang.org/t/julias-release-process/28122/6 "2019-08-29T01:20:55Z")

</div>

Is there going to be a way of bringing the 1.3 multi-threading stuff to Compat? To me, that seems a likely point for many packages to start dropping support for old versions.

---

<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:** [August 29, 2019, 2:19am UTC](https://discourse.julialang.org/t/julias-release-process/28122/7 "2019-08-29T02:19:50Z")

</div>

Definitely not. That’s not a thing you can bolt on.

---

<div class="post-metadata">

**Author:** ![tkf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkf/32/17635_2.png) [@tkf](https://discourse.julialang.org/u/tkf)\
**Post date:** [August 29, 2019, 3:06am UTC](https://discourse.julialang.org/t/julias-release-process/28122/8 "2019-08-29T03:06:12Z")

</div>

Somewhat tangential, but it’d be nice if there is a detailed write up like this for what it means to be a “public API.” I hope I don’t sound nitpicky, but without clear public API, a software is not really SemVer compliant. In particular, I think there are things that should be clearly documented that they are _not_ stable API (output (but not the calling convention) of `show`, type parameters of public `strct`s, etc.). I know Julia has `minor change` as a solution for something like this (and clearly explained in the blog post) but I think discussion in GitHub PRs and issues would be greatly simplified if it does not involve running PkgEval.

---

<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 29, 2019, 5:38am UTC](https://discourse.julialang.org/t/julias-release-process/28122/9 "2019-08-29T05:38:57Z")

</div>

> [@StefanKarpinski](#):
>
> I hope that all our diligence with making upgrades truly non-breaking will pay off by encouraging people to upgrade regularly without fear.

This is what I am counting on implicitly, so I just depend on 1.1 and then 1.2 when I need it.

---

<div class="post-metadata">

**Author:** ![nalimilan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nalimilan/32/147_2.png) [@nalimilan](https://discourse.julialang.org/u/nalimilan)\
**Post date:** [September 1, 2019, 3:29pm UTC](https://discourse.julialang.org/t/julias-release-process/28122/10 "2019-09-01T15:29:08Z")

</div>

> [@non-Jedi](#):
>
> Is there going to be a way of bringing the 1.3 multi-threading stuff to Compat? To me, that seems a likely point for many packages to start dropping support for old versions.

> [@StefanKarpinski](#):
>
> Definitely not. That’s not a thing you can bolt on.

Maybe @non-Jedi meant that Compat could include no-op functions/macros which would allow writing code that is threaded on Julila 1.3, but single-threaded on earlier versions? I guess that would be doable?

---

<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:** [September 1, 2019, 3:48pm UTC](https://discourse.julialang.org/t/julias-release-process/28122/11 "2019-09-01T15:48:40Z")

</div>

That could work. Good idea! It also matches the “sequential projection property” that we’re considering making a requirement for threaded code, which is basically that code should not deadlock if you delete all parallel macros and just run sequentially.

---

<div class="post-metadata">

**Author:** ![Tero\_Frondelius](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tero_frondelius/32/7629_2.png) [@Tero\_Frondelius](https://discourse.julialang.org/u/Tero_Frondelius)\
**Post date:** [September 1, 2019, 6:03pm UTC](https://discourse.julialang.org/t/julias-release-process/28122/12 "2019-09-01T18:03:42Z")

</div>

> [@tkf](#):
>
> what it means to be a “public API.”

My understanding is that “public API” is defined by `export`. Is it too narrow?

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [September 1, 2019, 7:28pm UTC](https://discourse.julialang.org/t/julias-release-process/28122/13 "2019-09-01T19:28:57Z")

</div>

Yes. Consider e.g. `JSON.parse` or `Meta.parse`, which definitely are part of the public API, yet aren’t exported.

---

<div class="post-metadata">

**Author:** ![tkf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkf/32/17635_2.png) [@tkf](https://discourse.julialang.org/u/tkf)\
**Post date:** [September 2, 2019, 3:11am UTC](https://discourse.julialang.org/t/julias-release-process/28122/14 "2019-09-02T03:11:46Z")

</div>

> [@Tero\_Frondelius](#):
>
> Is it too narrow?

> [@pfitzseb](#):
>
> Consider e.g. `JSON.parse` or `Meta.parse`

or `Base.@propagate_inbounds` or `Base.@pure`…

I also want to add that it is not only too narrow but also not enough. For example, `show(io, "text/plain", x)` pretty-prints `x` in a human readable form. But is `Base`/stdlib allowed to improve readability? If the exact output is documented to be a stable API, it is impossible. (See also: [Version doctests · Issue #1050 · JuliaDocs/Documenter.jl · GitHub](https://github.com/JuliaDocs/Documenter.jl/issues/1050))

Another example is that, say there is a custom vector type in a stdlib:

```julia
struct CustomVector{T} <: AbstractVector{T}
    ...
end

```

is it backward compatible to add one more type parameter?

```julia
struct CustomVector{T, S} <: AbstractVector{T}
    ...
end

```

It is compatible for user defining function `f(::CustomVector{Int})` but it is not for the usecase like

```julia
struct MyStruct{T}
    x::CustomVector{T}
end

```

because the field `x` will be boxed when a type parameter is added. IMHO Julia documentation should explicitly say that parametrized struct type must never be considered concrete. This means that you need to write

```julia
struct MyStruct{T, X <: CustomVector{T}}
    x::X
end

```

when performance matters. It also would be nice that each struct docstring defines what type parameters are considered public. The rule “parametrized struct type is not concrete” lets implementers hide some type parameters as implementation details. Another approach would be to say that only abstract types should be used for dispatch.

---

<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:** [September 2, 2019, 5:46am UTC](https://discourse.julialang.org/t/julias-release-process/28122/15 "2019-09-02T05:46:00Z")

</div>

> [@Tero\_Frondelius](#):
>
> My understanding is that “public API” is defined by `export` . Is it too narrow?

Yes, unexported symbols can be part of the API too, eg `Base.IteratorSize`, if they are documented.

Generally, packages also follow this convention: everything exported is part of the API, and in addition anything that is explicitly documented (in the docs, having a docstring is not enough). This is of course consistent with not exporting anything, just documenting a bunch of functions as your API. But there is no single formalized convention, so documenting what is and what isn’t part of your API is generally worthwhile.

---

<div class="post-metadata">

**Author:** ![Wenjie](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wenjie/32/10123_2.png) [@Wenjie](https://discourse.julialang.org/u/Wenjie)\
**Post date:** [September 4, 2019, 6:25am UTC](https://discourse.julialang.org/t/julias-release-process/28122/16 "2019-09-04T06:25:19Z")

</div>

Read it two days ago. Need a Chinese translation? I can help.

---

<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:** [September 4, 2019, 9:00am UTC](https://discourse.julialang.org/t/julias-release-process/28122/17 "2019-09-04T09:00:08Z")

</div>

That would be great. The process would be to make a pull request to add the translated post to [https://GitHub.com/JuliaLang/www.julialang.org/](https://GitHub.com/JuliaLang/www.julialang.org/).

---

<div class="post-metadata">

**Author:** ![Wenjie](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/wenjie/32/10123_2.png) [@Wenjie](https://discourse.julialang.org/u/Wenjie)\
**Post date:** [September 5, 2019, 11:47am UTC](https://discourse.julialang.org/t/julias-release-process/28122/18 "2019-09-05T11:47:04Z")

</div>

[Done](https://github.com/JuliaLang/www.julialang.org/pull/446).

---

<div class="post-metadata">

**Author:** ![jameson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jameson/32/23_2.png) [@jameson](https://discourse.julialang.org/u/jameson)\
**Post date:** [September 10, 2019, 1:17am UTC](https://discourse.julialang.org/t/julias-release-process/28122/19 "2019-09-10T01:17:22Z")

</div>

> [@StefanKarpinski](#):
>
> It also matches the “sequential projection property” that we’re considering making a requirement for threaded code, which is basically that code should not deadlock if you delete all parallel macros and just run sequentially

Woah, who’s considering going to do what now? I’m also not sure that deadlock-avoidance would even fall out of that since that’s a concurrency bug, not a parallelism one. Whereas sequential projection means that parallelism bugs are UB (maybe detectable?), but I don’t know if they claim any limits on concurrency.

---

<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:** [September 10, 2019, 1:21am UTC](https://discourse.julialang.org/t/julias-release-process/28122/20 "2019-09-10T01:21:10Z")

</div>

Talk to @vchuravy about Tapir.