Releases

The Business Cockpit has two kinds of user, and a release note has to answer both. An application which derives from the cockpit cares about Spring Boot, Java and the shape of what it overrides. A workflow module which reports to a cockpit cares about which VanillaBP it runs on.

The short version: the cockpit goes 1.0 together with VanillaBP 2.0, and everything below 1.0 is a step on the way there.

1. The lines
   Which version brings what, including the gap in the numbering.
2. Which cockpit goes with which VanillaBP
   The one table a workflow module needs.
3. What each step asks of you
   The work per upgrade, for a derived application and for a workflow module.

The lines

Version	What it brings
up to 0.3.x	Spring Boot 3, Java 17, a reactive backend
0.4.x	Spring Boot 4.1 and Java 21, still reactive
0.5 to 0.7	Held free. Nothing is released here except further work on the reactive line
0.8.0	The blocking backend: Spring MVC on virtual threads. The cockpit is split into a library and a container
0.9.0	VanillaBP 2. The version 1 adapters are removed, and the cockpit adapters move to a repository per BPMS
1.0	Released together with VanillaBP 2.0

The gap between 0.4 and 0.8 is deliberate. The reactive line may still need releases for applications which are not ready to move, and those get the numbers in between. So a version in that range is a source of the upgrade to 0.8.0, never a target.

Which cockpit goes with which VanillaBP

Your workflow module runs on	Use the cockpit adapters of
VanillaBP 1	The version 1 adapters of the cockpit repository, up to and including 0.8.x
VanillaBP 2	The three cockpit adapter repositories, from 0.9.0 on

The cockpit server itself is looser than that table suggests. What a workflow module reports travels over the REST or Kafka interfaces, and those keep their OpenAPI contracts across these versions, so a cockpit and a workflow module do not have to be upgraded on the same day.

The one artifact which does tie the two together is the Camunda 8 cockpit adapter. It is published once per Camunda 8 minor, the same way VanillaBP's own Camunda 8 adapter is, because the client a build was compiled against is the lowest cluster version that build accepts. Its versions therefore carry the line, for example 0.9.0-8.9.

What each step asks of you

Up to 0.4.0

Spring Boot 4.1 and Java 21. An application on 0.3.x or earlier carries that upgrade before anything else, and the cockpit is the smaller half of it.

Up to 0.8.0

This is the big one for a derived cockpit application, and nothing at all for a workflow module.

The backend was reactive and is now blocking. What survives is everything which is not a signature: the MongoDB data is untouched, no collection is renamed, the REST contracts keep their specifications, and the beans an application replaces keep their names, so whatever your application overrides today it still overrides afterwards.

What changes is the type of nearly everything crossing those beans. No Mono, no Flux, no ServerWebExchange, no ReactiveMongoTemplate, no SecurityWebFilterChain. One set of public constants is renamed as well, the request matchers of WebSecurityConfiguration, and that one breaks a derived security chain at compile time.

The second change of this release is the split: container used to be both the library and the application, and a derived application now depends on business-cockpit instead. Building a custom Business Cockpit describes what that means.

There is a skill for this upgrade, business-cockpit-upgrade-to-blocking in the skills repository. It surveys an application first and reports what it found before it changes anything, which is the useful part: the compiler finds the reactive code too, but one file at a time.

Up to 0.9.0

This is the big one for a workflow module, and small for a derived cockpit.

The version 1 adapters are gone from the cockpit repository, and a workflow module moves to the cockpit adapter of its BPMS, in that BPMS' own repository. Migrating from version 1 is that step, and it happens together with the move from VanillaBP 1 to VanillaBP 2.

For a derived cockpit there are two things. The first can wait. BusinessCockpitApplication is deprecated: the cockpit now arrives through auto-configuration, so there is nothing left to extend. The class is empty and stays until 1.0, so an application which still extends it compiles and behaves as before. Drop the extends and you are done, see Building a custom Business Cockpit. The same page lists the four Spring annotations which the cockpit now switches on for your whole application from the auto-configuration, each of which says so in the log on every start.

The second is the user interface. The jars of 0.9.0 carry none, neither io.vanillabp.businesscockpit:business-cockpit nor the runnable container, and no npm package of the cockpit is released with 0.9.0. The cockpit repository holds no user interface any more, and the sources of the old one are in its Git history. A derived cockpit which relied on the delivered interface now serves none, and a path no API knows gets 404. A cockpit which brings its own interface is not affected. Its index.html at classpath:/static/index.html, or wherever application.spa-default-file points, is served as before.

One configuration change in this release stops a cockpit from booting, and it is worth checking before you deploy. A template directory now says where it is, with classpath: or file: in front of it. That holds for business-cockpit.notification.templates.<medium> in the cockpit and for vanillabp.cockpit.template-loader-path in a workflow module. A value which was valid before and carries no prefix ends the boot, and the message repeats it with both prefixes so the fix is one line long. The gain is the other half: the notification templates may now come from a directory of the file system, so an operator changes the wording of a mail without a new build. Configuration has both keys.

Up to 1.0

Released with VanillaBP 2.0. BusinessCockpitApplication is removed here, so an application which still names it has to drop the extends before this step.

What is still open before it is written down where it belongs: a written description of what a cockpit user interface has to do, described under Customizing the user interface.

The seam letting a workflow module bring its own way of reporting is no longer among them. A bean of type BusinessCockpitTransport takes the place of REST and Kafka, which Connecting a workflow module describes.