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.
- 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.
8 Likes
This would be great in the Pkg.jl docs.
4 Likes
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.
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.
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.
4 Likes
see also the discussion here on this topic
1 Like
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.
6 Likes
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 
1 Like
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!
No one forces you to be up to date. You could skip every other update, for example.
4 Likes