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.