People seem to be piling on the OP for, from what I understand, their issues with simply running a small script that they got from a Juliacon video. I also found the OP gave suggestions and wanted to have a fair bit of discussion. Clearly, the OP is new to the Julia community including its development processes and the nature of packages. The OP is is using discourse as a means to interact with the community, which is perfectly fine. The OP should not have to learn how to navigate Github simply to point out their issues, their suggestions, and even their gripes. I am not really sure why the general sentiment of the replies were âyou are doing it wrongâ instead of actually helping the OP (as thatâs what I assume the intent is by engaging in the post in the first place).
This is clearly unhealthy and also is not the first time I have noticed this. As the language grows, there are going to be more permutations on how to do certain things. There are going to be folks who install Julia using binaries and have PATH issues because they found the install instructions on an outdated blog post. There are going to be folks who try to use newer features on older versions of Julia. There are going to be folks who install a newer package version, but hit an open bug from several versions ago. When these folks are frustrated that their tiny scripts are just erroring out and post on this forum, we should avoid the sentiment of blaming them for their issues. Rather, acknowledge that as the language grows, things are going to be fragmented and try to address their concerns.
With respect to release process, thereâs a difference between Julia and your experience with FreeCAD: FreeCAD is an application that produces products divorced from code, whereas Julia is a foundation for other code. Thus while FreeCAD betas target users, the core audience of Julia betas are developers. The beta period is a time for developers of key packages to try out the upcoming release and report/fix any issues. In general, people who are just Julia users should wait until release.
Why is this difference important? One of Juliaâs strengths is that much of Julia is written in Julia, and that means that many applications dive deep into Juliaâs internal representations. For example, the debugger based on JuliaInterpreter is a package, not part of Julia proper. However, as a debugger it needs to work with Juliaâs internal code representations at an early stage of the compilation pipeline. Such internals are explicitly not guaranteed to be stable, and really canât be if we want to see Julia continue to improve. (Many of the improvements from 1.0 to the present would not have happened if we required the internal representations to be fixed.) As a consequence, such packages often require extensive updating in preparation for a new release.
Of course, the vast majority of packages arenât affected by these internal changes: a well-developed package devoted to certain linear algebra operations, for example, should not require any updating to work on the latest release. But a lot of the tooling that sophisticated developers use to write such packages are affected by changes to the internals.
So think of a beta as a call to action by experienced Julia developers to start kicking the tires. Itâs definitely not intended for the audience you describe.
Julia 1.11.5 using a single thread compiles on Windows a simple module via PackageCompiler about 60 % slower than Julia 1.10.9. See my detailed test in this thread.
Maybe this is not the case on Linux, but this is why I opened the discussion.
Allow me to make another proposal:
all pinned projects in https://github.com/JuliaLang/ are treated as core components.
before a release is made all these projects are tested with the new Julia on Windows, Linux and MacOS.
If they work the first beta can be released.
If they work, but there is a major performance issue, the release of the beta gets information about this.
I think this will not block a beta release but a wide audience is then aware of issues and can help, test, develop patches.
I fully agree, and that is the point:
Since Julia is the foundation of code. Many people, developers like me need to take betas and test if their code is working well with it, and maybe adapt it to changed APIs. And of course they need to check the performance.
Take for example my case: I wrote now Julia modules for real-time evaluation of sensor data using neuronal networks. For me performance matters.
I am a beginner, but nevertheless a developer and release notes help a lot to save time. If it is e.g. known that PackageCompiler has a performance issue, I can have a look at that or I can put this aside, donât invest time on this but test other things.
That is not the case. As i was once the FreeCAD release maintainer, our betas are explicitly for developers. A big portion of FreeCADâs functionality exists in form of extensions. They are written in Python or C++. Every developer of an extension must take the beta and adapt his extension. And they also give feedback how the new beta performs. This was our understanding of beta testing. However, we had the policy to test FreeCADâs main functionality, and all the new features on all 3 major OSes before releasing beta 1. This saved a lot of troubles because then at least every new feature listed in the release notes was known to work under the different OSes and in that phase (letâs call it alpha phase) we ironed out most of the regressions.
Then during beta testing, we could focus on performance issues or maybe revert an API change that destroyed functionalities in extensions etc.
So FreeCADâs betas are for developers, âjust usersâ should want until the first release candidate. In that phase we tested for example the packaging of extensions, the Windows installer, Conda builds etc.
I feel compelled to point out again (re About Julia's development policy regarding Windows - #40 by danielwe) that every[1] registered Julia package is tested against the new Julia version before new releases. The reason PackageCompiler.jlâs regression slipped through was that its test suite doesnât check multihtreaded usage. No change to the release process would have caught this.
(Incidentally, I donât think @PatrickHaeckerâs PR adds a test either. This seems important to avoid future regressions.)
Itâs not perfect: PkgEval is currently Linux only, and it doesnât benchmark performance (that would require defining an interface for package performance benchmarksâmaybe not a bad idea?), but it will catch platform-independent bugs as long as the behavior is tested.
modulo abandoned packages that havenât worked in a long time âŠď¸
The only part of this that isnât already policy is that youâve decided that because PackageCompiler is a pinned repository in the JuliaLang repo we cannot make Julia releases if there are known issues with it. Thatâs simply not the policy, nor is it claimed anywhere to be the policyâitâs just a thing youâve asserted. Iâm sympathetic that you wanted to use PackageCompiler with a not-yet-released beta version of Julia, and it didnât work for youâthat is frustrating. However, mere presence of a repo in a GitHub org does not force us to block Julia releases; and beta releases are beta releasesâif they had no known issues they wouldnât be betas, theyâd be release candidates. I do appreciate that you want to build standalone, shippable Windows applications using Julia. This is very much something we want to supportâand we do, albeit with less smoothness than the more typical language use cases. Please try again after 1.12 final is released and a corresponding PackageCompiler release has been made.
I donât want to sidetrack this discussion, I just want to quickly answer on this relevant side-remark.
Thanks, I agree, that we should add this. Unfortunately, multi-threading is outside of what we can influence in runtests.jl, because we canât increase the number of threads from within a Julia process AFAIK. So the best way forward seems to be to activate multi-threading for the Julia process running the test-suite. This way all existing tests are automatically also testing multi-threading. But this is a separate thing and should be done in a separate PR. I created an issue. If anyone knows about how to do this in CI, please create a PR.
No, you misunderstood me. This thread is about to change the policy.
As I pointed out in my previous post, the release policy should be
a definition of core components (the community decides, not me)
a different understanding of a beta release
tests on all 3 major OSes for
the defined core components
all new features listed in the planned release announcement
So for example for 1.12beta, the first news item in the release announcement is the --trim option. 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.
No, the community doesnât decide. The core developers decide, and youâve gotten several core developers (including co-inventors of the language) to weigh in on this. I think everyone is very thankful for how deep youâve gone down this rabbit hole of identifying PackageCompiler problems, and documenting workarounds. It seems like the relevant issues have been filed and hopefully the situation will improve in the future (within the constraints of severely limited developer resources). I also think that people have taken note of your suggestions regarding the test and release process of Julia and some of the more exposed packages in the ecosystem. Nobody wants to have regressions, so to the extent that the developers of the packages can improve their processes, I believe that they will. Iâd leave it at that.
I think thatâs too pessimistic and more disempowering than the reality of it. Yes, there are core devs that make the final call on whether some issue should block a release or not, but that final call is not the whole decision making process. The GitHub milestones are used to track release blockers â and so if anyone is curious it might be worth just taking a peek at some of the discussions around milestone decisions. All it takes is someone making a bug report and asking!
The more engaged the community is, the more attention their packages get. And while PkgEval is linux only, most packages have CI setup on all platforms. A big reason for the beta release is to make it easy for package CI to grab it, along with a signal that you should start paying attention to (and reporting) the failures.
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 --trim option. 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 constrictive takeaways from this whole discussion should be. Two have already been done. First, there is a new Download 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.
Again, it is not me but the community that should decide what is part of the core functionality. I donât understand why the community should not do this, I think Julia is a community project. There is an annual conference, you can held even elections there, form a governing body for the Julia project or whatever. Many projects have such a structure, I like for example how KDE and the Wikipedia are governed.
New option --trim creates smaller binaries by removing code that was not proven to be reachable from entry points. Entry points can be marked using Base.Experimental.entrypoint (#55047).
This thread is about the development policy. And my opinion is that the development should have all the time all 3 major OSes in mind. A feature that is announced as new should have been tested under all OSes - directly when the PRs are reviewed and merged. So after a merge the new feature should work under all OSes. Sure, it might have bugs, but it should work somehow, or call it âbasicallyâ. --trim is an example that does not work at all under Windows in the beta1.
And when it is known that a new feature does not work under all 3 OSes, then there should be a note/warning in the release notes about this.
One should also consider features that are experimental not to announce as if they will become stable features with the final release. And I got the impression that --trim will not be stable when 1.12 final will be released.
I also stated that my intention is not to blame anybody, but to give an impulse that the development policy is changed/improved to have all the time different OSes in mind.
Yes and when I started to give Julia a try, I tried Juliaup. That time the Download page gave me the impression that I have to use the Microsoft store, which is not possible (many companies have disabled the store for legal reasons).
So I directly downloaded Juliaup, but on executing the Juliaup.exe nothing happened.
And this is another example on how a changed policy would help. I simply did not undestand that I have to execute juliaup from a console.
Most Windows users like me donât know a console. Also my clever colleagues holding a PhD in biology donât know about a console. And why should they? But they are the target audience of Julia.
Personally, I developed a lot in my life and cannot use a console because whenever I had to I just copy/pasted something I found in docs or a forum and that occurred few times a year. I cannot memorize commands and i am a chamption in making typos.
This thread is also about Windows and Windows users have other needs.
As Windows user I need a graphical installer where I can select at least:
the Julia version I want to install
the install location
All larger projects I know provide a graphical installer for Windows and a way to use it without the Microsoft store. And thatâs why I chose the graphical installer for Julia.
I cannot understand to hear in this thread that just because I need a graphical installer I made a mistake.
As I wrote installers for 2 lager projects (lyx.org and freecad.org) with over the time surely a million of installations, I could also write one for Julia but I have the feeling that there is not much interest.
That is not the structure that the Julia project has, though. To be fair, Juliaâs governance is a little diffuse, see Julia Governance. But it does not operate in the way the you envision, and I donât think thatâs going to change anytime soon.
Iâm not sure if you realize that youâre arguing with Stefan Karpkinski about how to best manage âhisâ own projectâŚ?
KDE and Wikipedia donât design programming languages, and neither of them would want any association in charge of a programming language to let all of its users decide core features. Letting developers and contributors who regularly work on a particular project have more of a say than everyone else is a good thing. Naive democracy isnât even on your side; despite the many things I have agreed with, at least in the moment (installation control, library reliability transparency, beta accessibility), I would vote with several people here against tying PackageCompiler releases to Julia releases. Excluding people who donât really know how these two projects work, like me, might actually tilt the scales your way. Depending on how juliac goes, this question may be moot anyway, but what do I know?
