If I may put my two cents… I’m reading about last problems and being Juce user for almost 10 years I noticed that such huge complications happen most often in plugins related stuff. Issues with base classes (usage independent) even if the classes are completely new or modified a lot are mostly minor and fixed very quickly and then such code stays stable forever.
When you reorganize plugins stuff there are always some troubles - no matter how much you modify the code. And to be honest it has to be like that (IMO) - plugins code is used in such different situations that I don’t believe that ‘stable’ state even exists. Even if you don’t make any changes then host apps/formats/OSes can change and cause the issues which need to be addressed.
It’s not about how to avoid the problems but how to live with them keeping peace of mind
Here I also vote my two hands for separating the branches for different purposes because it’s mostly about the JUCE repository management - the old hidden problems mix with the new unexpected problems from the outside world and mix with the fresh problems coming from new features not tested enough - and that’s the PITA. Using something similar to GitFlow management would fit perfectly here.
Having develop branch (and feature branches if you want) you could commit what you want - new turbo-ultra-inspiring features showing us where you want to go and giving us a chance to test it and giving you our feedback. All the revolutions go here and every bug is welcome.
One release branch if you decided that it’s good time for new Juce release. You close some state to test it more before it becomes new version. Only bugfixes are made to release branch and for example after 4 weeks you could simply release new version knowing that it’s as stable as possible.
Then we could always rely on master branch and use it for our important releases. And if anything from the outside world (hosts/OSes/compilers etc) cause the problems you could simply make a bugfix to the master branch (merging it also to develop branch or wherever you want).
I don’t agree that you at Roli should make all_the_tests for plugins stuff: all the major DAWs, OSes etc before committing anything. It’s waste of your time. Please focus on Juce development and make the basic tests only. If we had dedicated branches you could make deeper tests only on new releases and we could help you then testing it also on our sides. It would be great time saver for you and us.
Thanks @bld , I second everything in your post. Good to see that some people understand the place we are coming from!
In fact, we heard you and did introduce a new setup with two master and develop branches yesterday (see here). Hopefully this allows everyone here to work with the newest tip and test it in advance, while also having a stable branch available (master) that is only updated for critical bugfixes and actual releases of well-tested code.
Please keep in mind that JUCE used to be a one-man show with extremely minimalistic project management for a very long time (and that used to work very well!). So if we are to transition to more defined processes around releases, potentially a third branch for “release candidates” etc., and all those other things people are suggesting here, it has to be gradually and can’t happen overnight. Our first step are the two braches instead of one. We may do more stuff along those lines soon. Watch this space
Please stop repeating this straw man argument. No one has asked for ROLI to test every configuration, every time any change is made.
The request was: if ROLI makes MAJOR changes to the plug-in wrappers or the way they are built, those changes should be put through basic regression tests on the reference platform for each format: Pro Tools, Cubase, Logic.
We get that JUCE is a small team… but the fact is many of us who depend on JUCE and are calling for increased project management are one-man shops who already practice what we preach: strict release processes, separate stable/dev git branches, bug trackers, regression testing against reference platforms, semantic versioning, etc. We’re not advocating for anything we don’t do ourselves.
That said, I’m glad to see progress being made in this area. Change always feels difficult at first, but these process improvements really will make things better and easier for everyone - including ROLI - in the long run.
I wish This fantastic team was around for the Beta VHS wars.
Hey Juce,
Can you get this beta video working on my VHS video machine? While you are there, can you get this new DVD format working on the same machine? Don’t forgot to include this new security zoning system. The zoning system does not really work either, so can you fix that while you are getting those different formats working together. I already have my own fast forward, play and rewind working well. Please leave them out, if you include these you will only make things more confusing for my team.
Times have changed and the DAWs do not hold the power(monopolies) they used to. The plugin manufacturers should probably determine the ONE plugin format. Why don’t you super programming brains(which I am not), get together the day before the JUCE conference and start to take back a bit of control.
Just a silly thought.
PS Requirements in the plugin format will plateau out sooner rather than later. It will not always change at this rate.
and a thousand years from now in a DSP class.
Student-"but sir, why do we have six different plugin formats?"
Teacher-“What do you mean why! It is a thousand year old tradition. Do you dare question the foresight of our forefathers.”
The stupid outcome of previous format wars-
1Km is equivalent to 0.6214 miles.
The imperial (avoirdupois, or international) pound is officially defined as 453.59237 grams.
This would not affect me like it would a big developer, but I would be happy to put this at the top of my purchase page-
Please note- In order to simplify the plugin format and drastically improve stability and development, a number of developers have decided to create for(or it could be endorse) only ONE plugin format. Please be aware, before purchasing below, that after (some date) 2017 we may only support this new format. The following DAWs have agreed to extend support for(or it may be just support) this format.
(a list of DAWs).
Please support the DAWs who are willing to work for the greater good of audio and contact them about a cross-grade or pressure your current DAW to join this ever growing group.
Steinberg may be willing to allow VST3 to be handled by an independent panel of interested experts. That could be a bunch of high end programmers and possibly JUCE.
