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!

3 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?