Modules Status


#1

I’m running on a really ancient copy of Juce (1.54, grin), and after about 3 months of crafting my applications I should now take the time to restructure my project files and their relationship to Juce based on what I’ve learned.

Given that I want to bring an application to market, soon - should I move over to the modules branch now? Or should I just use the latest ‘non-modules’ version - I’d prefer to get this decision over and done with and not have to revisit it but I also need to have a stable release version.

Any thoughts on the matter folks?


#2

The modules branch includes so many fixes that I personally chose to make the move, after some time working on my test suite to be certain it wouldn’t break anything.
Now, it all depends if the changes included are required to market your product or not…


#3

Thanks Adrian - I would like to go with the branch that’s going to receive the most love and attention in the future. I’m guessing that’s the modules branch. Is it officially the ‘main codebase’ now? Or is Juce 2.x the frontrunner? If the modules branch is still in beta when might it become the leader of the pack?


#4

Risk / return is always a tricky question, especially when a product in in the home stretch. I started by doing some low priority/low risk things in Juce, so I didn’t hesitate to move to modules. For me, the transition was painless - BUT, your mileage may vary.

One thing that I like about modules is the option to copy them to a project. I like that what I check in and tag in .git for a release is complete. I don’t have to worry about falling out of sync with a separate juce folder. It’s also helpful because I’ve branched the library itself, extending socket stuff, filling in some not yet complete Android things, etc.

My point is just that, for long term product support stuff, the modules approach is pretty nice. It’s also probably easier to switch now than post release. But, again, you know the risks best and your mileage may vary.

As for ‘main’, Jules is the best authority on Jules’ thinking ;-), but it is hard for me to see modules not being the future of Juce now that the basic structure is in place.


#5

Unless you have written some really heavy customizations to the Juce classes or are depending on some obscure APIs, switching to the modules branch should require little to no effort on your part. It certainly should not require changing #include lines for a bulk of source files. At most you should have only 1 or 2 headers that include the required Juce headers, and just change those.


#6

If I remember well, in terms of code, I just had to work around the fact that Message doesn’t have its constructor taking ints anymore (so you’d have to subclass it), and a method to create an audio sample buffer from a reader that disappeared as well. That’s pretty much it.

Knowing that the JUCE_MAJOR_VERSION define changed to “2” in modules branch, that there is no backporting of bugfixes from modules to main, and that it is the result of a long debate on the forum, I’d say the modules branch pretty much IS “the future of Juce”. :slight_smile:


#7

Ok then, thanks guys - modules it is…probably this weekend.