JUCE_VERSION master and develop

Could the version number be bumped after the release instead of before?

I provide modules for juce for public use, so it needs to be compatible for the develop and master branch. When the API changes (e.g. CallOutBox 2 weeks ago) I cannot add an ˋ#if JUCE_VERSION > 0x60001ˋ, because master and develop have the same version number.

Solution 1: bump the version right after the release, so that develop has the future release number
Solution 2: bump twice and use even numbers for master and odd for develop, similar to linux kernel versions

That would help a lot, thanks for considering!

4 Likes

Little bump…
Any answer?

o yeah great
o no way
o not now, maybe next year

2 Likes

If we bumped the version number straight after a release you still wouldn’t be able to tell when a specific API change was present. If a consumer of your module was using a commit from the develop branch after a release, but before the introduction of the breaking change, this wouldn’t help.

A more sensible request would be to ask for JUCE to adopt semantic versioning, but that’s a much larger change to our workflow.

I think semantic versioning is the only way to deal with this?
It’s a pain to write libraries like this as it means bumping the version number a lot more or worse, putting off breaking changes simply to avoid bumping version numbers.

From a library writer that has a dependency on JUCE and after watching several talks from the maintainers of vcpkgs, I think the only way forward is to only support the tip. That could mean you have master/develop branches that mirror different JUCE branches but we just go with develop as that’s what we build with internally.

Fair point. I don’t expect to know every git commit. I just want my users to be able to use my module.

A normal user has the choice to follow master or develop. Those are the versions I care about. And as soon as you change something on develop, I have the chance to fix it. We are moving in pairs, and I can tell my users to update to the latest tip (that’s what you tell your users as well when they report errors).

When the develop is released (merged on master), this number as well as the changed API becomes fact, and all keeps working. I don’t think it needs to be more complicated than this.

As an example, when the API of CallOutBox was changed, I can simply add the new usage and master and develop will still work:

#if JUCE_VERSION > 0x60001
        juce::CallOutBox::launchAsynchronously (std::move (newColourPanel), getScreenBounds(), nullptr);
#else
        juce::CallOutBox::launchAsynchronously (newColourPanel.release(), getScreenBounds(), nullptr);
#endif

I don’t think so. Juce moves very linearly, and that is great. So there is always a point in time, when the change happened. I think it is only necessary to catch that point, and the user just needs to move together with the develop.

99% of the users don’t fix in juce, and if they do, they are able to do this on their own and don’t raise support requests. We just need to support the master and develop scenario IMHO.

EDIT: I just finished reading the semantic versioning link. That is what we are doing now, isn’t it?

By definition all breaking changes happen between master and develop. They never happen at any other point, so all is well if we simply have a different version number for master and develop.

@t0m, I really can’t see the problem here, nor an alternative. But I am open to suggestions how I can support master and develop.

The objection is that a solution that only works most of the time is much more confusing.

Can you have a develop and a master branch of your module?

It works on very well defined situations, which are the two latest tips, master and develop, as well as every previously released version.

Which means that I have to cherry pick every commit I do and get unnecessary complexity, if a future feature relies on the API change.

Isn’t it a legit request to have any form of distinction between the master and develop branch?

I hit this problem again:

The juce::AlertWindow::IconType was moved to juce::MessageBoxIconType, which is a good move.
However it leaves me again in the situation I cannot add macro to have the latest master and latest develop in a functional state. For the users either main or develop is broken.

For this specific case a simple line in AlertWindow would have worked:

class AlertWindow {
public:
    using juce::MessageBoxIconType=AlertIconType;
    // ...
};

But if the version number of the latest develop would be different from latest master I would add a workaround in my code.

And no, maintaining four branches is not an option (foleys main with juce master, foleys main with juce develop, foleys develop with juce master and foleys develop with juce develop)…

Or what was the idea of your suggestion @t0m ?

Would be great if that problem could be solved either way…

This may not help you but I ran into this with Surge recently trying to have it compile against 6.0.7 and also against develop while using one of the new features. The way I solved it in my cmake was to set a flag based on a detection of version. In this particular case I did

set(SURGE_JUCE_VST3_EXTENSIONS FALSE)
if(EXISTS ${SURGE_JUCE_LOCATION}/modules/juce_audio_processors/utilities/juce_VST3ClientExtensions.h )
  set(SURGE_JUCE_VST3_EXTENSIONS TRUE)
  message( STATUS "Including JUCE VST3 Client Extensions")
else()
  message( STATUS "No JUCE VST3 Client Extensions" )
endif()

then based on the SURGE_JUCE_VST3_EXTENSIONS flag I later on in my cmake file set a target_compile_option then in my code do


class SurgeSynthProcessor : public juce::AudioProcessor,
#if SURGE_JUCE_VST3_EXTENSIONS
                            public juce::VST3ClientExtensions,
#endif
                            public SurgeSynthesizer::PluginLayer,
                            public juce::MidiKeyboardState::Listener

or whatever.

Basically since the version collapses between latest stable and master, I write little cmake rules to figure out if i have the feature I want in JUCE then turn it on. I’ll go back and remove these when I move my submodule to 6.1.

If you wanted to be cleverer you could also use check_cxx_source_compiles which we didn’t have to do for JUCE but did have to do for other submodules we have.

this of course assumes you are cmake not projucer. And its just what I figured out and may not work for you. but it did work for me so figured I’d share!

Thank you for that suggestion. I am sure in cmake you can do a lot of clever tricks. But I don’t supply project files, and I don’t want to write cmake howtos for the users of my module. I am busy enough writing howtos how to use the GUI editor.

I want to keep my audience for my module as big as possible, so I don’t force them to choose between cmake or projucer. I have a cmake project for github actions but also test from time to time the Projucer projects.

Like I said before a few times in this thread, the users would expect to be able to use either juces master or develop branch. It is completely understandable that it won’t work for every commit of juce, because we cannot detect the version on commit level. But it would be sufficient to be able to fix everything for develop once it happens and make the fix backwards compatible relying on JUCE_VERSION.

Again, the solution I see is to bump the version on develop after release. But I am open to other suggestions, that allow the code to be compatible with develop and the different releases.

I have to apologize, I don’t know in which state my project was, but it seems there is a backward compatibility AlertIconType in the AlertWindow. I have to blame my Xcode. The old code compiles now with all versions.

Would still love to have the distinction just in case for future API changes, but have no recent cause now.