Any work in your PR will not be merged into any other branch in this repository, but will instead be reproduced in our private repository. We may refactor and rewite any code submitted to us in PRs.
Does this mean any PRs won’t be credited to the original author, since they’re reproduced in another repo? Or will the author of those reproduced commits be assigned to the original author of the PR?
The presence of the PR doesn’t change the priority of the underlying work.
We have only merged one PR, and that PR was a bug fix. As a general rule, if things are broken in the framework then fixing them will be prioritised over additions or improvements. This is shown pretty clearly in the list of our recent commits.
We have additional bug fixes to address before we will consider more cosmetic changes. As bug reports arrive at an unknown rate, and with unknown severity, it’s not possible to give a satisfying estimate for when we will have the bandwidth to evaluate and test other PRs. If a PR is clearly a poor enough fit for JUCE that the idea contained within it will never be merged then we will close the PR, but otherwise we will keep it open.
If the PR requires a substantial re-write, or is otherwise difficult to slot into the series of commits currently in progress in our private repository, then the original author may get lost. We will try to maintain the original author, but we are not making any guarantees.
We won’t be drawn into a long process of nudging the original author to incrementally improve the PR until it is ready for inclusion without modification. This would be a very poor use of the JUCE team’s time, where we could instead be focusing on things that have a much higher value.
Is there any form of roadmap for juce? Are there parts of the library you consider complete / deprecated that won’t be getting improvements going forward? i.e. would you recommend not using the box2d module since it’s now about 10 years behind the main box2d code and will never be updated? juce_analytics and juce_osc don’t seem to be getting updates either?
Are there parts of juce that are only there for backwards compatibility and shouldn’t be used in new projects?
Sadly things can never be complete because environments like Apple’s and others’ keep changing and we all need to play catch-up, and JUCE supports a lot of environments!
Surely something like juce::Array<> is finished…?
The problem with juce::Array is it can actually be much quicker than std::vector for primitive types as it can realloc which the std:: containers can’t do. So using it in time sensitive places makes a lot of sense. But I agree it should be a “performance” container rather than a general purpose one.
Other than fixing typos, juce::Array was last updated in September to make use of C++14’s [[deprecated]] - so it’s safe to assume areas of the codebase will be continuously updated as JUCE updates to newer and newer versions of C++.
The ‘soft’ in ‘software’ refers to the fact that it can easily change and adapt - so I don’t think it’s right to say any piece of software is ever ‘finished’.
I like to understand the term “finished” rather in a life cycle manner. That code needs to be touched from time to time is obvious and undisputed.
But the more interesting question is:
Is there code that works now, but we won’t bother to improve or adapt it and won’t use it ourselves?
An example where we got a statement is the ComponentBuilder, which is used in the old Projucer GuiBuilder, but it is deemed end of life and will rather be replaced completely if at all.
Sounds like the same could be said about box2d according to @RolandMR.
Such information would be extremely valuable to plan ahead!
I think the term here is “legacy”.
I’m excited about the possibility of contributing!
The JUCE team trawls the forums for the big/urgent stuff. So it sounds like smaller bug fixes and warnings would be the most valuable PRs for the community to submit at the moment, is that right?
Are you interested in documentation additions / corrections as PRs at this time?
Our highest priority tasks are fixing errors in the framework. If there’s some documentation that is incorrect it is likely that we will incorporate those changes fairly quickly. If, however, the changes are more cosmetic then reviewing them will be a lower priority.
