# About Julia's development policy regarding Windows **URL:** \ **Category:** General Usage\ **Tags:** windows\ **Created:** [April 12, 2025, 7:29pm UTC](https://discourse.julialang.org/t/about-julias-development-policy-regarding-windows/128011 "2025-04-12T19:29:51Z")\ **Posts on this page:** 1\ **Showing post:** 39

**Author:** ![goerz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerz/32/3269_2.png) [@goerz](https://discourse.julialang.org/u/goerz)\ **Post date:** [April 14, 2025, 1:03am UTC](https://discourse.julialang.org/t/about-julias-development-policy-regarding-windows/128011/39 "2025-04-14T01:03:34Z")

Sorry, but you are getting _way_ off base here! > [@uwestoehr](#): > > > [@ufechner7](#): > > > > Not so sure which installer you are talking about, > > The [official one](https://julialang.org/downloads/#manual_download). 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) > [@uwestoehr](#): > > After installing Julia, there is no command `juliaup` You got it wrong. You install `juliaup`, and `juliaup` installs Julia. > [@uwestoehr](#): > > And then I should become a customer of Microsoft and its store just to be able to use 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](https://github.com/JuliaLang/juliaup?tab=readme-ov-file#windows) (with lots of caveats, so not supported/recommended). > [@uwestoehr](#): > > I needed to install Julia for all users of a computer. As of now there is a bug in the Julia installer. 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. > [@uwestoehr](#): > > The first case is for example that _juliac_ hardcodes a `cc` compiler. With a proper policy, someone would have said in the PR revision process to think also about Windows Yeah, maybe. But I’m not 100% sure that’s not deliberate: > [@uwestoehr](#): > > The second case is that _PackageCompler_ that always downloads MinGW-w64, also if it is already installed and in the PATH variable. Because the development is not done with having the different OSes in mind. 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](https://docs.binarybuilder.org/stable/). Using some binary that may already be on the system and that may or may not be compatible is a recipe for disaster. > [@uwestoehr](#): > > the bug is reported and verified [since months](https://github.com/JuliaLang/PackageCompiler.jl/issues/990), but new Julia 1.11 releases were made 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. > [@uwestoehr](#): > > > [@](#): > > > > Ah, stupid me, how could I assume, [PackageCompiler.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/PackageCompiler) a package that is hosted in the official [Julia repository](https://github.com/JuliaLang), meaning it has the same status as [Pkg.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/Pkg), Juliaup and Julia itself, is production-ready. That tells a lot about how QA is handled in the Julia project. > > That might sound rude 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](https://discourse.julialang.org/t/about-julias-development-policy-regarding-windows/128011/9) 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. > [@uwestoehr](#): > > > [@goerz](#): > > > > I was not under the impression that `--trim` is intended to be complete > > It is the first item in the [release announcement](https://github.com/JuliaLang/julia/blob/v1.12.0-beta1/NEWS.md). > And of course I expect every entry in the NEWS.md file to have been tested before a beta version is released. 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. > [@uwestoehr](#): > > Of course, everybody has a different understanding of QA should be done, but I cannot find any info of QA is done in Julia. I mean there is a release team and they must follow any kind of QA/checklis/release procedures. 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? > [@uwestoehr](#): > > there is a checklist for releases, containing > > - tests for all supported OSes > - all items in the NEWS.md file are tested > - first if all checks are OK, a release will be 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](https://github.com/JuliaCI/NanosoldierReports). > [@uwestoehr](#): > > All checklists (release and QA) are publicly visible and are created together with the Julia community Julia’s development is completely public on GitHub. > [@uwestoehr](#): > > Beta versions are released without the new features of a version were tested on the 3 main OSes Nonsense. The CI for Julia runs on all supported platforms. > [@uwestoehr](#): > > There are no rules and checklists how a release is made 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. --- _[View the full topic](https://discourse.julialang.org/t/about-julias-development-policy-regarding-windows/128011)._