Some of these features are intended as JUCE 5 headline features to be officially released later this year. However, as these features required substantial changes to some of the core functionality of JUCE, we would like to pre-release these features on the develop branch.
This will give you the opportunity to test the new features, integrate them into your workflow and provide us with valuable feedback.
Disclaimer on Licensing of the develop branch
The source code available in the develop branch is provided for testing purposes. JUCE offers no guarantee that the source code will be integrated to the JUCE framework. The source code can be used for commercial and open source releases following the terms of the JUCE license. Many of the new features presented here will ultimately be released as part of JUCE 5 and using them in closed source application will require a paid license. Please contact info@juce.com for any questions or visit the JUCE forum at forum.juce.com.
Hi Fabian. These changes look very good at first glance and it is certainly a good idea to let some of us trial run these. But - the licensing disclaimer is a huge problem for me.
What I believe this means for me is that I have to decide now whether I want to upgrade to Juce 5. If I adjust my work in progress to work with these changes (esp. multi-project-exporters which need adjustments to installers and build infrastructure), I basically cannot easily go back anymore and I already now have decide to upgrade toi JUCE 5 once it comes out. I’m not ready to do that without knowing more about it. So overall these changes mean to me the develop branch has become useless and a no-go. Unless I am mistaken the disclaimer basically means using the develop branch code in a commercial product requires a JUCE 5 license. This is “buying the cat in the bag” (german idiom, like “pig in a poke”). It would feel much better if the JUCE 5 only stuff was on a separate branch. Unless the JUCE 5 release is imminent of course and no more JUCE 4 updates are planned…?
In my humble opinion a more sensitive approach would be to give the features that you think require community testing to license holders without strings attached. The people willing to test the new stuff are providing free testing to you after all.
Hi pflugshaupt, thank you for your opinion! Let me try to clarify a few things. First of all, you can use the develop branch with a JUCE 4 license and release a commercial product. Your JUCE 4 license is valid for both the master and the develop branch until we release JUCE 5. Does this make sense?
Obviously, releasing a commercial product from the develop branch can be risky as we may make breaking changes and do not do hotfixes. Furthermore, JUCE 5 will contain many, many more features - which we will not release on develop - so it will still be worth upgrading.
So I’d like to argue that it’s quite the opposite of “buying the cat in the bag”. With the develop branch, you can now test and have a play with the new JUCE 5 features without immediately needing a license.
What do you think?
Edit: Removed sentence: “Once we release JUCE 5 you can still use the old JUCE 4 develop branch but you are not allowed to git pull anymore without buying JUCE 5”. This needs to be clarified with JB.
Hmm this just isn’t clear enough I’m afraid. If I now switch my build system to multi-target and then decide in the future I do not want to upgrade to JUCE 5… Will I be allowed to release a product with the multi-target option or not?
Let me clarify this with JB, but the way I understand it is that you can release a product with the multi-target option, but you must base your product on the state of the potentially buggy develop branch as it appears a few moments before we release JUCE 5. Therefore, the develop branch will also not contain most new JUCE 5 features as we will release some of them on master immediately.
JUCE 5 will be publicly released in a matter of months. The new code released on the develop branch is intended to give everyone a heads up of what’s coming, and identify and fix bugs before they’re released as part of JUCE 5. The terms of the JUCE 4 license however apply to it: you can use this code for open source applications, or if you are a JUCE 4 license holder, you can use this code in closed source apps, too. We don’t guarantee however that this is free of bugs, or that the we will release fixes before we launch JUCE 5. So, to continuously use bug fixes and features that we’ll add as part of JUCE 5 and release on master, you will eventually need a JUCE 5 license.
Yes we’re pretty much set on the price of JUCE 5, and the price of the upgrade from a JUCE 4 license. No surprises to expect. We’ll communicate the details within the next two months, before JUCE 5 is out to allow everyone to plan accordingly.
Question: suppose I decide for the moment to stay with JUCE 4 (hence no purchase of JUCE 5 license yet).
Also suppose that, after release of JUCE 5, a bug which was still there since JUCE 4 appears and gets fixed (on develop, I suppose).
The question is: Am I allowed to cherry-pick the commit that fixes that JUCE 4 bug, on top of my copy of JUCE 4, even if that was appended to the JUCE repo after the release of JUCE 5?
Thanks for clearing things up. I don’t understand the point of that development branch disclaimer then. No one expects the develop branch to be bug free.
I hope the majority of the JUCE team is now finally working on one of the main promised features of JUCE 4: The DSP module. This must be your top priority now, right?
Honestly, if you now start adding JUCE 5 exclusives to the development branch you just make it harder for yourself to create a version 4.3.x with that DSP module included but without those J5 features. Or does it just mean that the DSP module is now finally off JUCE 4?
Why not put this mostly finished (since Nov 2015) DSP module on the development branch right now and get some feedback from the community?
Some context:
A selling point for JUCE 4:
“Coming soon, the DSP module is a compilation of signal processing utilities grouped into one library” (404 - Missing Page - JUCE, after ADC 2015)
When a new version of JUCE launches, the support we provide for JUCE 4 will be extremely limited. This is to allow us to maintain one reliable version of JUCE.
If you are concerned about backward compatibility, then I would recommend to test from time to time with the develop branch and raise any concerns ahead of the release to give us time to fix issues and ensure that new features don’t break your code.
