Implementation Roadmap & Future Design

This document outlines the planned improvements, feature priorities, and strategic vision for jhelm.

1. 1.0.0 — first stable release

jhelm 1.0.0 is the first stable release on Maven Central, defined by two things being true at once: a broad real-world conformance bar and a stable, extraction-ready engine and API.

1.1. What 1.0 delivers

Area Delivered in 1.0

Conformance

540 / 540 real-world charts render byte-identical to helm template in CI (the parity suite, charts.csv), order-independent, with only a small set of documented comparison-ignores (random/timestamp names, generated secrets/certs, and the known non-semantic differences in Interoperability).

Engine

The Go template + Sprig engine ships as the standalone gotmpl4j library on Maven Central; jhelm consumes it as a dependency and keeps only the Helm-specific function layer (jhelm-gotemplate-helm).

Chart lifecycle

install / upgrade / rollback / uninstall / list / status / history / get / template / package / lint / dependency, plus hooks, JSON-Schema validation, and Helm-faithful SemVer version selection.

Repositories

HTTP and OCI repositories with digest verification and recursive dependency value coalescing.

Real cluster

.Capabilities populated from the live cluster and the lookup function querying it (returning full resource data, as Helm does during install/upgrade); template --kube-version / --api-versions overrides for offline rendering.

Provenance & security

Chart signing / verification (PGP), opt-in SSRF protection for server mode, and host-gated repository credentials.

Distribution

Published modules: gotemplate-helm, core, kube, rest (+ starter), mcp (+ starter), plugin. The jhelm CLI and sample apps build from source and are not published to Central. All quality gates (spring-javaformat, Checkstyle, PMD, JaCoCo) are green on a full ./mvnw clean verify.

API stability

The public surface was frozen in 0.4.0 (below) and is documented in API Surface & Stability; 1.0 commits to it under semantic versioning.

1.2. API freeze (shipped in 0.4.0)

The pre-1.0 API freeze milestone landed in 0.4.0, settling the public surface ahead of a stable 1.0. The supported surface — and the .internal convention that separates it from implementation detail — is documented in API Surface & Stability:

  • Unchecked exceptions — the action layer and KubeService throw the JhelmException hierarchy instead of throws Exception.

  • No leaked Kubernetes-client types — ApiException/ApiClient are wrapped behind KubeClient; BouncyCastle PGP types behind SigningKey/VerificationKeyring.

  • Options objects — the action API takes immutable InstallOptions/UpgradeOptions/ UninstallOptions/RollbackOptions instead of long parameter lists.

  • Immutable result models — Release/ReleaseInfo/MapConfig are immutable; release status is a typed ReleaseStatus enum and the lifecycle phase a LifecyclePhase enum.

1.3. Post-1.0 direction

The phases and design below are forward-looking. The near-term priorities after 1.0 are Server-Side Apply in HelmKubeService, structured logging, and closing the remaining OCI and gitlab value-coalescing gaps; the longer-term vision is the Spring Boot management platform described at the end of this page.

2. Recommended Implementation Roadmap

The roadmap is divided into several phases focusing on compatibility, feature completeness, and architectural modernization.

2.1. Phase 1: Helm 4 Core Compatibility (2-3 weeks)

  1. Add missing template functions (mustToYaml, mustToJson, etc.) - ✅ COMPLETED

  2. Category-based function refactoring - ✅ COMPLETED

  3. Remove duplicate legacy functions - ✅ COMPLETED

  4. Implement Server-Side Apply in HelmKubeService

  5. Enhanced OCI registry support with digest verification

  6. Content-based chart caching

  7. Multi-document values file support

2.2. Phase 2: Feature Completeness (3-4 weeks)

  1. Dependency management system

  2. Hooks support (pre/post install/upgrade)

  3. Missing commands (get, show, dependency)

  4. JSON Schema validation - ✅ COMPLETED

  5. Improved resource status watching

2.3. Phase 3: Architecture & Quality (2-3 weeks)

  1. Remove Spring Boot from core modules (making them library-first)

  2. Async/reactive support - ✅ COMPLETED (virtual-thread AsyncKubeService)

  3. Metrics and observability

  4. Enhanced error recovery

  5. Better contextual error messages

2.4. Phase 4: Advanced Features (4-6 weeks)

  1. Plugin system architecture

  2. WebAssembly plugin support

  3. Post-renderers

  4. Chart signing/verification

  5. Chart testing framework

2.5. Phase 5: Polish & Performance (2-3 weeks)

  1. Template compilation cache - ✅ COMPLETED (LRU TemplateCache)

  2. CLI color output

  3. CPU/memory profiling

  4. Enhanced test coverage

  5. Documentation improvements

3. Compatibility Matrix

Feature Helm 3 Helm 4 jhelm Current Priority Status

Template Rendering

✅

✅

✅

-

Complete

Sprig Functions

✅

✅

✅

P1

✅ Complete (minor gaps tracked in Function Coverage)

Helm 4 must Functions*

❌

✅

✅

P1

✅ Complete

Server-Side Apply

❌

✅

❌

P1

Pending

Three-Way Merge

✅

❌

✅

P1

Complete

Plugin System

✅

✅ (new)

❌

P2

Pending

OCI Registries

✅

✅ (enhanced)

⚠️

P1

Partial

Chart Dependencies

✅

✅

✅

P2

✅ Complete

Hooks

✅

✅

✅

P2

✅ Complete

JSON Schema

❌

✅

✅

P2

✅ Complete

Content Caching

❌

✅

✅

P1

✅ Complete

Structured Logging

❌

✅

⚠️

P1

Partial

4. Spring Boot Integration Roadmap ⭐

4.1. Strategic Vision

Transform jhelm into an enterprise-grade Helm management platform powered by Spring Boot, offering:

  • Centralized Configuration: Spring Config Server integration for values management across environments.

  • REST API: Full-featured API for programmatic Helm operations.

  • Web UI: Modern web interface for chart management and deployments.

  • Multi-tenancy: Support for multiple teams, clusters, and environments.

  • Real-time Operations: WebSocket-based deployment status and logs.

  • Enterprise Features: Security, audit logging, RBAC, SSO integration.

4.2. Architecture Design

4.2.1. New Modules

Module Description

jhelm-server

Purpose: REST API and Web UI server.
Technology: Spring Boot 4, Spring Web/WebFlux, Spring Security.
Components: REST Controllers, WebSocket endpoints, Web UI integration, OpenAPI docs, Actuator metrics.

jhelm-config

Purpose: Configuration management and Spring Config integration.
Technology: Spring Cloud Config, Spring Profiles.
Components: ConfigurationProperties for Helm values, Profile-based config, Config Server client, Encryption support.

jhelm-security

Purpose: Authentication, authorization, and audit (Future).
Technology: Spring Security, OAuth2, JWT.
Components: RBAC for Helm operations, SSO/LDAP integration, API key management, Audit logging.

4.2.2. Enhanced Existing Modules

  • jhelm-core: Add @ConfigurationProperties, Spring Environment integration, Spring Events for deployment lifecycle, Spring Cache for template caching.

  • jhelm-kube: Reactive operations with Spring WebFlux, Spring Retry for resilience, Spring Cloud Kubernetes for discovery, Async deployment support.

  • jhelm-cli: Read from Spring Config Server, support environment variables via Spring Boot.

  • jhelm-gotemplate-helm: Remains lightweight, no Spring dependency (pure Java), tracking the external gotmpl4j engine.