Core components of Julia are everything that ships with Julia itself. PackageCompiler does not ship with Julia, thus it is not a core component. We try not to break it, of course, but if there is an issue in PackageCompiler that isn’t Julia’s fault, then that does not block a Julia release. If we held up Julia releases for every package that someone somewhere thinks is important, then we would never get releases out—and they already take a very long time.
- a different understanding of a beta release
We use a pretty standard definition. To quote wikipedia: “A beta phase generally begins when the software is feature-complete but likely to contain several known or unknown bugs.” In this case the “bug,” as I understand it, was lack of clarity in release notes about limitations of an experimental feature. Anyway, it’s good that the release note got clarified before the final release.
- tests on all 3 major OSes for
- the defined core components
- all new features listed in the planned release announcement
We do all of this and much more.
So for example for 1.12beta, the first news item in the release announcement is the
--trimoption. But that was not tested under Windows. Such a test should be done before a beta is released for the reasons I gave in my previous post.
The --trim feature is explicitly experimental. It even requires the --experimental flag to enable it. The release notes should have been clearer about that, but again, they were non-final release notes, and there’s still the flag which should make it clear. Experimental features may not work everywhere.
I’m trying hard to figure out what the constructive takeaways from this whole discussion should be. Two have already been done. First, there is a new Install Julia page that very aggressively recommends using juliaup to install and manage Julia versions, on all platforms. This should prevent some of the issues you encountered from making non-standard installation choices. Second, the release notes for 1.12 have been improved.
I’m having a harder time with the others. For example, you seem to want us to consider PackageCompiler a “core component” of Julia. It isn’t and we don’t want to do that. In the future, once juliac is no longer experimental, we will likely fold the functionality of PackageCompiler into juliac and then that will be a core component since we ship it with Julia. Until then, it’s not. I suppose we can more officially document what is or isn’t a “core component”, but this is the first time this issue has come up in the 15 years I’ve been working on this, so I’m not sure one person’s misunderstanding warrants that. You thought it was, there was a big discussion, now you know that it’s not.
Another thing is that you’ve urged us to do is to “take Windows seriously”. But of course, we do. Windows is not a second-class platform. It’s tested as much as any other platform and, aside from experimental features which may not yet work everywhere, features must work on Windows. The Windows issues you hit were a combination of choosing a non-standard installation process and using an experimental feature in a beta release. So once again, I’m not sure what to do differently here. We would always love more Windows-centric developers and testers, of course, but I don’t think there’s any policy or procedure to change.
More testing? Nothing here was a testing issue, except for the missing threading test for PackageCompiler. I’m sure that will get fixed and tests added. Missing tests are always a possibility. One adds the missing tests to make sure things don’t regress in the future. No policy or procedure to change—just add the tests.