Acustica has been releasing updates of all engines for 12 years following the continuous delivery approach.https://en.wikipedia.org/wiki/Continuous_delivery
We were pioneers, and it was fitting very well for a start-up company. Still we think this is the best approach to development, and still we are alone in the market with this innovative vision of development, and users can access freely and frequently to new updates, which could fix even recent issues in a very elegant way, instead of waiting for months or years.
Normally this kind of delivery is based on very short communication, especially notices about new releases and changelogs. This kind of delivery is also the one followed by Apple, Facebook and Google: when you open app store and you download an update in most of cases you read simply a row reporting “bug fixes”. They don’t tell you they fixed the menu bar or memory leaks. Bug fixing means that the application is following planned rules, instead of doing a different action.
With the introduction of the Aquarius platform we can finally manage the continuous delivery in a more elegant way: the user simply opens Aquarius and he pushes a button, updating all plugin versions at once. In order to make it safe, we are pioneers of “continuous downgrade approach”: if the new version doesn’t work you can simply restore a previous version (we are innovating here, even Apple is not doing it and a wrong update could lock your beloved applications for a while).

Problem arises with the old legacy system, and we were still providing engine executables in separate downloads, very often without many explanations. This approach fits perfectly the continuous delivery approach: if a new engine is not working you can revert to a previous one easily, just replacing again with the previous version. We see there are COMPLAINS, and people basically is expecting from Acustica the “traditional release” model, where few releases are announced with an increased beta-testing time and a frozen fixed set of features. Even if we keep repeating we are not Slate, Uad, or Softube, someone is expecting that specific approach, simply because it is very common.
While we are still merging this model with our historical one (you have Ivory2, Ivory3 releases following the traditional model and a number of intermediate versions following the continuous delivery model) we see that we cannot join completely this model, because our culture. We’ll never be Waves, even with the current increasing company growth size. A square thing will never be round.

We are trying to merge those two approaches and we have a new set of rules.
This is the state-of-art:
- Acqua plugins, and soon Nebula 4 will be hosted in Aquarius. You can expect there the complete absence of notifications via email. We expect you open the application often, you check if a product is asking for being updated and you decide what to do. If a new release is creating issues you can still downgrade to the previous installed release.
- We are still providing legacy installers, in such case you should rely on your download folders, checking the release date. When you see a new version without any additional text, it is because there “a bugfix”. You will NOT be notified via email, for the exception of MAJOR updates (the switching from Ivory2 to Ivory3). Normally we send newsletters for most of MAJOR updates, but there could be exceptions. Keep in mind the “news product alert” section in our Acustica-audio.com forum IS the official place where we announce MAJOR releases.
- All our features are extensively listed in our user manuals. The only exception today is Nebula, but we are going to fix completely the Nebula situation in march, listing also the new features there.
- We REMOVED all previous standalone executables, engines (dll, vst, components, aax) in ANY form from our website, your dashboard, our official links. If you see we forgot someone, please report them, we’ll remove the remaining links quickly.
Basically we understand that when a “feature” is creating “complains” (in this case the engine distributable model) and we simply don’t agree on the proposed solutions, we simply remove it.