I don’t see it that way. I think all your points are important and valid, and core developers are/will read this and consider them seriously. What maybe is drifting is the expectations on what can be done objectively in a short terms and by whom.
8 Likes
- When I don’t feel like opening a PR, sometimes I open an issue instead.
- Is there something specific you found lacking regarding the documentation?
You’re right, it’s not clear enough from that note that the feature is still experimental. Opened two new issues:
3 Likes
From what I can tell the main “checklist” for a release is in the milestone section on github GitHub · Where software is built
But I also not sure why a beta version was released when there are still known release blocking issues.
For me the default program for a .jl file was notepad. I can change the default program to be the julia executable though and then it works to just double-click the file to run it. Though the window closes as soon as the program finishes, but I’m sure you can solve that for a GUI somehow.
I do agree with this sentiment, so it is nice to hear that you managed to get it working without 
While not exactly what you are asking for, I vaguely remember the Julia discourse got support for “wiki” threads or something like that a few years back, where everyone could collaboratively edit a post on a topic? While I don’t love the discourse search, I think a lot of good information is already documented here and is often not too hard to find. So if you find a topic lacking, maybe trying such a thread to gather all information for other users could be one way to go?
4 Likes
See also the one-click (actually, a double-click) install of VS Code/VS Codium + Julia on Windows:
1 Like
On the one side, as I wrote recently in a different topic,
On the other side, the instructions on the download page are not perfect, for macOS as well as for Windows.
Where should I go to make a PR?
2 Likes
Done:
1 Like
That’s exactly the difference between a beta and a release candidate. If there were no known blocking issues, it would be a release candidate (which would then become a release unless issues were found). A beta is just a chance to more easily try out the new version before it’s fully ready.
11 Likes
For the record the multi-threading bug you ran into is not specific to Windows, and is equally problematic on Linux.
1 Like
I think you got my point: it is not about a particular bug, it is about the development policy.
How are things developed, how is the QA handled, how is the release process, where are the checklists to review PRs, the announcement texts, test results etc.?:
Proposal for better development policy
- PRs sent in for the components of the main Julia GitHub are only merged, if they will work on all supported OSes
- 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
- there is a definition of what a beta release should be (in what state and what should be the outcome of the release), the same for release candidates.
- if an item in News.md is reported not to work, no release is done, until this is fixed or removed from the news/announcement.
- All checklists (release and QA) are publicly visible and are created together with the Julia community
2 Likes
I see now, but is is a good example of the development policy problems of Julia. In that case:
- there is a regression bug in one of the core components of Julia (worked in 1.10.x, fails in 1.11.x)
- the bug is reported and verified since months, but new Julia 1.11 releases were made
- instead of fixing existing regressions a beta of a newer Julia release was made.
There is obviously (my opinion) a QA issue in the development policy. If the release team would say, we release despite the known regression and explain this, OK, there might be reasons. But known regressions must be part of release announcements. But neither in a release announcement nor the bug report, there is info why new releases were made before fixing the regression.
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.
1 Like
This was already pointed out: it’s not a “core component”, or a component at all, it’s just a package in the ecosystem.
2 Likes
Imo, PackageCompiler.jl should be core functionality and prioritized accordingly.
1 Like
As I wanted to trigger a discussion about the policy not a specific case, let me give you an example:
I needed to install Julia for all users of a computer. As of now there is a bug in the Julia installer. Instead of opening a new forum thread and posting my workaround/solution, I would have quickly changed this page:
if it were a Wiki page. Then it is directly documented and other can benefit from it. Once a fix is available, I or another one can change the Wiki page.
But https://julialang.org/downloads/platform/#windows is not a Wiki. No user can “just” add or update info. Moreover, one first had to search around who to inform and on what channel. And making maybe in the end a PR for a documentation is hefty. Meaning making the PR is much more work than to edit directly a Wiki page.
As I mentioned, I was part of FreeCAD’s core team and can tell that the Wiki improved the docs a lot. The docs are kept up to date by a community, basic users can just make a change, and we also use it for QA.
1 Like
To cite myself:
That might sound rude but why do we discuss what a core component is rather than how to improve the QA process and the development policy?
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.
11 Likes
I understand your frustration. However, I’m not sure this is a process problem. Julia runs the test suites of the entire ecosystem of packages before every new release of the language to assess if the changes introduce any breakage (look at PkgEval.jl and Nanosoldier.jl to see how this is done). The unfortunate fact here is that PackageCompiler.jl’s test suite doesn’t test compilation in multithreaded julia processes, so this bug slipped through the cracks. The remedy is to add such tests to the PackageCompiler.jl test suite. I have a hard time seeing how a different process would have helped as long as the crucial test was missing. I agree that this breakage event was very unfortunate and I hope some qualified devs find the time to fix the bug and add the concomitant tests.
5 Likes