Now that we’ve released Julia 1.0 and are close to 1.0.1 and have added some new features and minor changes to the 1.1 development branch (i.e. master), it seems like time to talk about the future of the Julia release process. After various discussions in person, on Slack, and on this week’s triage …

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 binari…

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 about MbedTLS. Sometimes that implies staying with an older version just for th…

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

[image] 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…

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.

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 …

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.

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 woul…

[image] 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 …

[image] Palli: I’m not sure it says that It definitely does : 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 release…

Proposed release process and schedule

Internals & Design

Topic		Replies	Views
RFC: give up on SemVer Internals & Design semver	36	2411	October 9, 2023
Guidelines for committing to v1 release Community	25	1661	February 15, 2020
Julia 1.8, 1.9 (rapid release?) General Usage	16	3469	August 19, 2022
Enough deprecations! Internals & Design	24	3561	August 1, 2018
1.0 adoption path? General Usage	76	14498	July 21, 2018

Proposed release process and schedule

Related topics