Many thanks for the discussion and the input!
Allow me to sum up the issue from my perspective:
- as it is there is room fro improvement, I think that many agree
- it is not about blaming, but to improve the situation by making proposals, think about the proposals and then maybe at the next JuliaCon to discuss it and then implement something
- I mentioned some issues as example not to work and fix them particularly but as an example to trigger a discussion about the development policy.
Here is my proposal refined, having in mind to use the community:
-
the community, (for example every discourse user with a certain trust level) can vote for packages to be in a Tier group. He has as many votes as the Julia team lead decided there should be e.g. Tier 1 packages.
-
If for example there can be 10 Tier 1 packages, everybody has 10 votes, the top 10 voted packages become Tier 1, the next 10 packages Tier 2, there is no Tier 3 or below.
-
The result is a list of e.g. Tier 1 and Tier 2 packages, that are for the community so important that they should be tested before a release candidate in a way that
- all package functionalities work on the 3 major OSes, MacOS, Linux and Windows
- the performance is not worse (execution speed, compile time etc.) except there is a technical reason. In that case the reason will be given in the release notes
-
The Julia project lead can define how they handle Tier 1 and Tier 2 packages. For example if Tier 1 should be tested before beta, or after etc.
-
Every year there is a new vote because things might change. That does not mean that packages are no longer respected, only that it won’t be a teamup with the release team and the package maintainers.
What would be the benefit?:
- Julia and and package developers are not the same, so there will be a teamup before the release to quickly/directly exchange test results, feedback, regressions, different user perspectives etc.
- the release announcements get more info. For example what is still experimental and why, what is the plan until the release, what regressions are known and the developers are aware of under the different OSes
Back to the examples I gave, this would improve the situation:
- the Julia project lead get feedback what is important for the community, thus it can steer the Julia development in that direction if they want
- new experimental features like --trim are directly in the release notes declared as experimental, and there would be the info, that it is known that it does not yet work under Windows. And there will also the info that it is listed as new feature because the development sees good chances to get it production-ready for the final release. Or the announcement can also be that --trim will not be production-ready for reasons also given in the announcement.
- If e.g. PackageCompiler, Pkg, Flux etc. are in Tier 1, then there cannot be a final Julia release before these packages works well with that new Julia under the major OSes. For the community counts that Julia + the desired packages work well together. For the example PackageCompiler its 60% performance loss with Julia 1.11 under Windows would either lead to another release candidate of Julia in which that issue is addressed in Julia code. Or if only code changes in PackageCompiler are necessary, the final Julia release would be hold back until the issue is resolved in the package.
This is my proposal. Maybe some will be taken out of it, maybe not. I made it to be constructive because complaining is easy, improving sometimes difficult. But to improve things, there must be different proposals/ideas/options that can be discussed and evaluated.