Sorry, but you are getting way off base here!
You missed the top of that page. The official installer is juliaup. The downloaded binaries are very much secondary (but they also do, in fact, work)
You got it wrong. You install juliaup, and juliaup installs Julia.
You can’t seriously make the argument that “Windows is the most important platform” and then turn around to say “I don’t want to use the Microsoft store”. But even then, there are alternative installation instructions that bypass the store (with lots of caveats, so not supported/recommended).
That is not a bug. That’s something that’s deliberately not supported. Julia is installed in user space on all its supported problems. That’s a question of security, plus, the majority of Julia users need to install Julia on systems where they do not have admin/root access (like HPC clusters).
So, with all of the above, you are just not following the installation instructions, and you are going out of your way to use unsupported setups. I’m not sure why. It makes it pretty hard to take your concerns seriously.
Yeah, maybe. But I’m not 100% sure that’s not deliberate:
I’m pretty sure that’s not the reason. Julia packages that use binary artifacts completely package those artifacts. We have an entire system built around that. Using some binary that may already be on the system and that may or may not be compatible is a recipe for disaster.
It’s not a bug in Julia so why should a Julia release have any relation to a bug in PackageCompiler? (I do agree that is a nasty bug, and I’m sorry you had the bad luck of running into it. And yes, it should be fixed sooner rather than later, but I can’t exactly make demands on the developers of PackageCompiler). Even if the development team of PackageCompiler has a large overlap with the core developers of Julia, it’s a completely separate package with a separate version number and release process.
It not just might sound rude, it most definitely is rude. Maybe take some time to actually get familiar with the community and Julia’s development process before making these kinds of demands on “QA”.
Other comments on this thread have pretty conclusively demonstrated that installing Julia on Windows works just fine. Your issues are mostly of your own making.
PackageCompiler is NOT a core component. Your insistence that it should should make some kind of QA guarantees in relation to Julia releases in completely unfounded. That’s just not how open source works.
The release notes say that a --trim flag was added. It doesn’t say anything about the scope of that feature or how stable it is. I don’t even think were at the point where the full functionality of --trim is fully specified, so I don’t know what “tested” is supposed to mean on this context.
I can assure you there are. Development is organized on GitHub, and a lot of discussion happens on Slack. There are also regular public meetings, which you are welcome to join if you want to engage with Julia’s core development. But I also would point out that Julia is an open source project. There are over 4000 open issues. You expect these to be closed before a new release is made?
I don’t know about “checklists” (you insistence that such a thing should exist seems rather idiosyncratic to me), but Julia has extensive automated testing and very high levels of QA. In fact, they not only verify that the tests in the Julia tests pass, they even test the entire ecosystem of registered packages for regressions.
Julia’s development is completely public on GitHub.
Nonsense. The CI for Julia runs on all supported platforms.
Not true. There are no releases made with failing CI runs.
Your demands on Julia’s development process are unwarranted. I can assure you that Julia works just fine for a great many computational scientists. There’s definitely room for improvement, and I’m not denying that you’ve raised some valid issues. But at this point, we’ve left the road of reasonable input.