I think your disclaimer says something different.
Yes, they will require a paid license when JUCE 5 is released.
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.
Looking through the commit log, JUCE just shed so much gross old support code. It’s beautiful!
Since I’m not shipping commercial products, I’ll bite the bullet and jump off master to try and find bugs.
And there’ll be more purging to come as we get more momentum on our use of C++11 features!
Thank you for the question.
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.
Hope this clarifies our intentions.
Have you decided on the cost to upgrade from a full lic. of JUCE 4 to a full lic. of JUCE 5 yet?
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.
Great news ! The Standalone format is a very good idea and will be useful to a lot of JUCE commercial plug-ins devs !
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?
No - everything we do after the release will come under the JUCE 5 license.
Any indication of upgrade cost? Are we talking 20%, 50%, 75% of current license costs? If I know I’m going to upgrade then makes this decision easier…
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.
Surely I will buy JUCE5, But I would like to continue getting support (bug fix) for JUCE4.
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?
A selling point for JUCE 4:
“Coming soon, the DSP module is a compilation of signal processing utilities grouped into one library” (https://www.juce.com/releases/projucer-juce-4, 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.
It’s a fair point. Samuel. The DSP module will not be released as part of JUCE 4. I can only apologise for making promises that we couldn’t keep.
Bear with us while we finalise the details. We’ll communicate the details before the launch.