Skip to main content

Roadmap

The WKS Platform roadmap outlines our vision for providing a robust, modern, and secure Business Process Management (BPM) and Case Management solution. We follow a versioned release strategy, focusing on stability, security, and developer experience.

Platform Evolution​

v1.4.14​

Theme: Maintenance & Support

The previous stable line, on Java 17 and Spring Boot 3.x. It continues to receive maintenance updates through the v1.5.x migration grace period — see the Support & Release Policy.

v1.5.0 (Current Release)​

Theme: The Stabilization Release

The current release. A stabilization release that hardens the existing platform: upgrading core dependencies to current LTS/supported versions and clearing High and Critical vulnerabilities, without changing the application's capabilities.

  • Zero-Vulnerability Baseline: Elimination of all High and Critical CVEs across the platform.
  • Java 21 & Spring Boot 4: Transition to the latest LTS and next-gen framework standards.
  • Camunda 7.24 Integration: Optimized workflow engine performance and long-term support.

v1.6.0 (Next — In Development)​

Theme: The Configuration Standard & Document Management

The next release consolidates the platform's foundations into a governed, versioned, enforced configuration contract, and introduces Document Management as a first-class, config-driven capability. It builds directly on the v1.5.0 stabilization — same runtime stack (Spring Boot 4.0.6 · Java 21 · Camunda 7.24) — now with stronger guarantees about what configuration is valid and what a case type requires.

Pillar 1 — The Configuration Standard & foundations (delivered on develop)

  • A published, versioned Standard: case-type configuration (Case Definition, Form, Record Type, Queue) is now a documented, versioned set of JSON Schemas — one source of truth shared by the backend, the portal, and tooling.
  • Enforced on write: the API validates configuration on create/update and rejects non-conforming documents, turning the Standard from advisory into a real contract.
  • Structural validation: checks beyond schema shape — e.g. a stage-transition hook can't target a stage the case type doesn't define.
  • A real CI safety net: pull requests are gated on unit + integration tests (previously silently skipped) with coverage reporting, so regressions are caught before merge.
  • A resilient portal: failed API calls surface as clear errors instead of vanishing; a bad payload degrades gracefully instead of white-screening.
  • Dependency governance: grouped, reviewed dependency updates that keep framework upgrades deliberate.

Pillar 2 — Document Management (in progress)

  • Config-declared document requirements: case types declare the documents they require, and each case surfaces a completeness checklist.
  • Storage modes & durable references, document lifecycle (verify / reject with server-stamped actors), and versioning (re-upload supersedes the prior version) — landing as a stacked series of slices, the first of which is in review.

Breaking changes

  • kanbanConfig removed from the Case Definition contract (Configuration Standard → 2.0). Kanban board columns now derive from a case type's stages; per-card presentation moves to a separate, versioned board-config artifact — see the @wkspower/case-config-schema changelog. The removed field was deprecated and empty across all shipped case types.

Planned & Future Vision​

Theme: Deliberate Modernization & Depth

  • Complete the Document Management arc — remaining slices (search / preview, retention, versioning polish) beyond the first Document Management release.
  • Spring Boot 4.1 + springdoc-openapi 3.x — a deliberate, verified framework-minor upgrade. springdoc 2.x is incompatible with Spring Boot 4 (the Swagger UI is affected), so the two move together as one reviewed change rather than an unvetted auto-bump.
  • Persisted board-config store — the board-config schema is published (Standard 2.0); a backing store/endpoint follows when there's a concrete need for per-card presentation.
  • Repository-backed configuration checks — extend structural validation to cross-document integrity (e.g. a Case Definition's formKey must reference an existing Form) at the domain command layer.