Proposed release process and schedule

Which of these various releases and pre-releases will have binaries available?

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).

1 Like

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. You’re definitely safe if you stick to things that are both exported and documented.

1 Like

I’m not entirely clear what you mean by this question. All releases have binaries. Release candidates, alphas and betas (where relevant) also have binaries. The only things that doesn’t have a corresponding binary release is the warning announcement before a new patch release.

This sounds good to me. Does this versioning include stdlib?

At some point I seem to remember it being suggested that we could use different versions of stdlib with different versions of Julia. (E.g. get the latest base but keep an old version of some stdlib package if necessary.)

That will be possible at some point but we don’t have the technical ability to do that yet. We won’t make breaking changes to stdlibs until we can though.

Perhaps I missed the point of Python’s future (totally possible, I’m not very into Python world), but I’ve always seen Compat.jl as its Julia’s equivalent, isn’t it?

For what it is worth, I thing a lot more people would test patch pre-releases if you provided binaries. Ideally, these binaries could just become the official patch binary after a suitable amount of time.

Release candidates do and always have had binaries. So have alphas and betas. And there are also nightly builds in general.

1 Like

He is referring to patch releases. The recent “Test 1.0.1” post did not mention any binaries but only building the corresponding branch yourself. But is this not some kind of release candidate?

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.

5 Likes

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 the LTS.

3 Likes

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

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.

3 Likes

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.

A post was split to a new topic: Thoughts on eventual Julia 2.0 transition

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.

4 Likes

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 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.

6 Likes

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.