# Proposed release process and schedule

**URL:** <https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623>\
**Category:** Internals & Design\
**Tags:** proposal, releases\
**Created:** [September 28, 2018, 3:43pm UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623 "2018-09-28T15:43:12Z")\
**Posts on this page:** 20\
**Page:** 2

<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 30, 2018, 1:46am UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/21 "2018-09-30T01:46:17Z")

</div>

Doing release candidates for patch releases was deemed to be overkill; it’s quite a lot of work and the changes should be low risk, so we’ve decided not to do it. If we can make it easier to do automatically generate the binaries in the future then we may have nightlies that can serve as test binaries for patch releases.

---

<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 30, 2018, 9:03am UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/22 "2018-09-30T09:03:24Z")

</div>

Regarding long-term support releases, something to keep in mind is that we should pick versions of the dependencies which are also LTS where possible, especially for security-related libraries. See for example [this issue](https://github.com/JuliaLang/julia/pull/28759) about MbedTLS. Sometimes that implies staying with an older version just for the LTS.

---

<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:** [October 1, 2018, 2:03pm UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/23 "2018-10-01T14:03:51Z")

</div>

Yes, that’s definitely a good think to keep in mind.

---

<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:** [October 1, 2018, 4:39pm UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/24 "2018-10-01T16:39:53Z")

</div>

> [@StefanKarpinski](#):
>
> Minor releases may include bug fixes, new features and “minor changes”—which is the term we’re using for technically breaking changes that are sufficiently unlikely to break anyone’s code _and_ which do, in fact, not break anything in the package ecosystem as determined by running PkgEval and verifying that there isn’t any breakage.

I wonder if not breaking **any** packages isn’t too restrictive. With the number of (registered) packages growing so rapidly, chances are that for some “borderline public” API features there will be packages that rely on them.

I think this could be handled on case-by-case basis: if a single or a handful or packages would break, maybe their maintainers could be notified so they could fix/change this behavior instead.

---

<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:** [October 1, 2018, 5:30pm UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/25 "2018-10-01T17:30:09Z")

</div>

Yes, I think that as long as end users are able to upgrade everything easily and smoothly then that is sufficient. Judgement will be required.

---

<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:** [October 1, 2018, 6:57pm UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/26 "2018-10-01T18:57:30Z")

</div>

Split this topic on October 1, 2018, 6:57pm UTC

A post was split to a new topic: [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:** ![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:** [October 3, 2018, 9:46am UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/27 "2018-10-03T09:46:59Z")

</div>

I wonder if your proposal could address changes to the related tools that are not strictly speaking part of the language spec, but are nevertheless important.

Eg Julia 0.7/1.0 introduced the new package/project format, which is amazing until one actually registers the package, then learns that the whole framework relies on the old `REQUIRE` format which is (again, strictly speaking) no longer part of the language spec, and the new format is pretty much ignored by the registry pipeline.

Eg when the these things change, the maintainers could commit to waiting with the release of Julia until the related tools catch up to a reasonable extent.

---

<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:** [October 3, 2018, 1:39pm UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/28 "2018-10-03T13:39:48Z")

</div>

I’m not sure what the ask is here. We are going to move away from REQUIRE to Project.toml at the same time as we move from METADATA.jl to the new General registry.

---

<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:** [October 3, 2018, 1:51pm UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/29 "2018-10-03T13:51:09Z")

</div>

Just to clarify: what I am suggesting is some level of (soft) commitment to not leaving the combination of the language + related tools in an inconsistent state for too long.

In the particular case, imagine a the situation of someone who started using Julia with 1.0. To register packages, they would use `REQUIRE`, which is not even documented in the (current) manual. Conversely, their `Project.toml`, which is the documented solution, would be ignored by the current registry pipeline.

I recognize Pkg2-\>Pkg3 has been a significant change, and getting here was possible with the dedicated, hard work of a group of people. I am just suggesting something for the future, at least for minor version bumps.

My suggestion is not about Pkg in particular, but all the tools which are not part of the language _per se_, yet used in connection with Julia. I think this affects user choices about which version to use at least as much as breaking changes in the language.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 16, 2018, 3:38pm UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/30 "2018-10-16T15:38:42Z")

</div>

> [@dlfivefifty](#):
>
> Also, I believe SemVar says anything goes with 0.x releases. So if you are risk adverse don’t use any 0.x packages (such as DataFrames).

I’m not sure it says that, but anyway, Julia is what’s bound by SemVer, any “0.x” text may have applied to Julia, not packages you use with. To Julia, while it see’s the version number of packages, all individual packages are treated the same, and none should be broken by Julia bugfix updates.

---

<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:** [October 16, 2018, 4:00pm UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/31 "2018-10-16T16:00:26Z")

</div>

> [@Palli](#):
>
> I’m not sure it says that

[It definitely does](https://semver.org/#spec-item-4):

> 1. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

However, the convention for Julia itself has been that `0.x.(y+1)` releases are patch releases and only include bug fixes while `0.(x+1).0` releases are major release which have both new features and breaking API changes. The alternative interpretation is that `0.x.(y+1)` releases may include new features as well as bug fixes, but that seems less likely to be useful. I would strongly encourage packages to follow Julia’s interpretation and consider which of the following stages their project is at:

- `0.0.x` — **sketching** : there will be no bug fix release or feature-only releases since the API is still being worked out; every release will break things, add features and fix bugs all at once. Consider whether it even makes sense to make published releases at this point.

- `0.x.y` — **exploring** : the project is mature enough to have bug-fix-only releases for people who want to stay on a particular version and still get fixes for things that are broken. However, the project isn’t mature enough that it makes sense to make feature releases without also taking the opportunity to make breaking API changes.

- `x.y.z` — **stable** : the project now has a stable, well-established API. It is mature enough to warrant both bug fix and new feature releases where no breaking API changes are made. At some point it may make sense to make breaking changes based on what’s learned from this major release version but not in the immediate future.

---

<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:** [October 16, 2018, 4:02pm UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/32 "2018-10-16T16:02:35Z")

</div>

This would be great in the `Pkg.jl` docs.

---

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 16, 2018, 4:07pm UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/33 "2018-10-16T16:07:58Z")

</div>

> [@StefanKarpinski](#):
>
> > I’m not sure it says that
> 
> [It definitely does](https://semver.org/#spec-item-4):

Yes, but I meant, SemVer doesn’t say a major version, e.g. Julia 1.0, can break 0.x packages (rather than 1.x packages).

I was answering for that. Julia 0.x.y could have done whatever, but I viewed it as major updates, for ony increase in x.

---

<div class="post-metadata">

**Author:** ![laborg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/laborg/32/5474_2.png) [@laborg](https://discourse.julialang.org/u/laborg)\
**Post date:** [October 24, 2018, 7:54am UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/34 "2018-10-24T07:54:19Z")

</div>

> [@StefanKarpinski](#):
>
> What exactly constitutes the public API of Base code needs to be spelled out in greater detail, but the convention at this point is mostly around export: if something is exported, then it’s public, if it isn’t, even if it’s documented, it should be presumed to be internal—although the documentation really should say that.

Is this done already? I’m currently wondering if a field of an exported exception is part of the API or not. eg.: `T` in `InexactError`.  
The first post is well written, very helpful and would deserve to live somewhere in the manual, possibly including thoughts on the _constitution of and public API_.

---

<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:** [January 24, 2019, 8:44am UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/35 "2019-01-24T08:44:36Z")

</div>

Just a bit of reflection on developments after 1.0: since 1.1 contains so many nice new features _and_ bugfixes, I may just find it much easier to require 1.1 in my packages when they get a rewrite, simply to economize on developer effort.

I am still pondering over this, since it would mean that the “(very) low risk tolerance” users stuck on 1.0 for some reason either won’t get upgrades. I may have a biased view, but for interactive work (data analysis, model estimation, plotting) I think it is not unreasonable to just keep up with the latest minor release (perhaps after a tolerance period of a few weeks, for the extra-cautious). In the unlikely case that things break, one can always go back to 1.(x-1) and backport.

---

<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:** [January 24, 2019, 9:36am UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/36 "2019-01-24T09:36:20Z")

</div>

> [@Tamas\_Papp](#):
>
> since 1.1 contains so many nice new features _and_ bugfixes, I may just find it much easier to require 1.1 in my packages when they get a rewrite, simply to economize on developer effort.
> 
> I am still pondering over this, since it would mean that the “(very) low risk tolerance” users stuck on 1.0 for some reason either won’t get upgrades.

see also the discussion here on this topic

> [@Julia v1.1.0-rc1, the first 1.1 release candidate, is now available](https://discourse.julialang.org/t/julia-v1-1-0-rc1-the-first-1-1-release-candidate-is-now-available/19172/14):
>
> That makes sense, but my question was subtly more general than your answer satisfies. I’m also asking about the more general case when v1.x is released, let’s say v1.2, then it is recommended to continue testing for compatibility with v1.0 and v1.2, since v1.0 is long term. However, because v1.1 is a short term release, is it recommended to drop it from testing and only continue with v1.0 and v1.2 compatibility? Otherwise, the tests would keep getting longer and longer with each version. It do…

---

<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:** [January 24, 2019, 5:42pm UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/37 "2019-01-24T17:42:25Z")

</div>

If you need or even want lots of upgrades for Julia or packages then I think that you are by definition not in the “very low risk tolerance” persona. New features are inherently risky, don’t use them or software that depends on them unless you are willing to accept a chance of breakage.

---

<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:** [January 24, 2019, 11:15pm UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/38 "2019-01-24T23:15:02Z")

</div>

It seems that, if there are users clammoring for it (and at least some that are willing to put in the effort), one could have long-term stable releases of packages that go with the long-term stable Julia releases and get bug fixes back-ported, while also having new development branches.

But I’m worth you - I plan to develop for the leading edge, and since I’m the only one using my packages anyway, I doubt it will be a problem 😆

---

<div class="post-metadata">

**Author:** ![opera\_malenky](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/opera_malenky/32/8213_2.png) [@opera\_malenky](https://discourse.julialang.org/u/opera_malenky)\
**Post date:** [January 25, 2019, 3:24am UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/39 "2019-01-25T03:24:01Z")

</div>

Just as a single data point (the plural of anecdotes not being data, etc.), I’ll say that I work in a particular (very very large) entity where getting approval for updated software can be a huge pain… as in, it took nearly 2 years to get R approved and installed for us (!!!).

The one bit of wiggle room we have is that we can (for now) get “.X” releases approved. So 1.1, 1.2, 1.3, etc. are all (hypothetically) good… but 2.0 would trigger a gigantic new painful approval process. If even _that_ (the .X release) moves too fast, it can get really sticky for us.

Frankly, R moves a little bit too fast in terms of point updates for our process… I like nice updates, but if you can move a bit slower than R in terms of .X releases, it’d make my life (and potentially the life of thousands of other researchers) infinitely easier!

---

<div class="post-metadata">

**Author:** ![carstenbauer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/carstenbauer/32/4981_2.png) [@carstenbauer](https://discourse.julialang.org/u/carstenbauer)\
**Post date:** [January 25, 2019, 6:24am UTC](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623/40 "2019-01-25T06:24:58Z")

</div>

No one forces you to be up to date. You could skip every other update, for example.

[Previous page](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623.md?page=1)

[Next page](https://discourse.julialang.org/t/proposed-release-process-and-schedule/15623.md?page=3)