eurofunk Kappacher GmbH

Established Company

Show all Videos

Effortless Versioning

Stefan Höller von eurofunk Kappacher zeigt in seinem devjobs.at TechTalk, wie das Unternehmen die Versionsverwaltung bei langen Produktzyklen mithilfe von Semantic Release gestaltet hat.

By playing the video, you agree to data transfer to YouTube and acknowledge the privacy policy.

Video Summary

In Effortless Versioning, Stefan Höller shows how his team replaces “God components” with a focused Angular component library designed in Figma, documented in Storybook, and run as a multi‑repo for resilience. He details a pipeline using GitLab CI, Renovate, and semantic‑release where Angular‑style commit messages drive semantic versioning, tags, changelogs, and automatic publishing; in a live demo, fixing missing global styles triggers a patch release (2.4.2→2.4.3) and updates a consuming app. Viewers learn a practical workflow to avoid bloated components, keep APIs clear, and ship incremental, traceable releases without manual version wrangling.

Effortless Versioning in Practice: How Stefan Höller at eurofunk Kappacher GmbH Tamed Library Releases with Semantic Release, GitLab, and a Multi‑Repo Strategy

Why this talk matters

In “Effortless Versioning,” Stefan Höller of eurofunk Kappacher GmbH walks through a grounded, real‑world account of library versioning in a large engineering organization: long product lifecycles, more than fifty frontend developers, and a growing set of shared UI components. The punchline is not a new framework or a shiny tool for its own sake; it’s a disciplined approach to change, captured in commit messages and executed by a CI pipeline. We at DevJobs.at followed his narrative closely because it answers a stubborn question in modern frontend engineering: How do you keep a component library healthy over many years without drowning in manual release overhead?

“I don’t need to think about versioning anymore, which is great. I can just release it.”

The starting point: a big monorepo and growing “God components”

Höller’s context will sound familiar to many:

Product cycles lasting 15 years or more
50+ frontend developers
A large monorepo

Over time, reusable building blocks like selects, buttons, and accordions had evolved into “God components” — small things that tried to do everything. He illustrated it with a select component that had accreted features: combo‑box, search, single and multi‑select, pagination, lazy loading, virtual scrolling, and more. Every new feature increased the fragility. “We added something, we broke it, we fixed it, we broke it again” is the kind of maintenance treadmill no team wants to be on.

The counter‑strategy: a standardized library with a clear scope and API

The team decided to standardize. Their goals were explicit:

A well‑defined scope for each component
An API that is easy to understand and consume
Thorough documentation
Reuse across multiple products

To support this, they set up a three‑part foundation:

Figma for visual design and mockups
Angular for implementation
Storybook to document and showcase the library

This combination matters: Figma defines what should exist, Angular delivers how it works, and Storybook explains the why through states, examples, and usage narratives.

Where should the library live? Monorepo vs multi‑repo

The next decision was about repository strategy:

Monorepo
Pro: easy to integrate, easy to access
Con: also easy to change in ad‑hoc ways; small one‑off features can creep in, feeding the very complexity they wanted to avoid
Separate repository (multi‑repo)
Pro: resilience to change; every alteration must be crafted, planned, and designed, not just blended into product code
Con: more ground‑up work; integration is not automatic

Höller’s team chose the multi‑repo route because resilience was the priority. The library needed its own lifecycle and governance, decoupled from the daily churn of product development.

Roles and responsibilities: Tech leads, UX, and frontend

Ownership was equally clear:

Tech leads as the technical drivers
A UX team with the experience to design interactions
Frontend engineers to implement the Angular components and supporting tooling

This delineation avoids “hero” maintenance. Strategy and quality sit with the leads, design authority with UX, and production‑grade code with frontend.

Maintenance without manual toil: GitLab and Renovate

For maintenance, the team leaned on automation:

GitLab hosts the code and runs pipelines that enforce quality gates and release steps
Renovate detects outdated dependencies and opens pull requests to update them

Renovate eliminates the recurring “every few months” chores. Instead of someone remembering to check which dependencies are stale, the bot proposes updates continuously. Often the team can just merge; sometimes small adjustments are needed. Either way, the important bit is that no one has to remember — the system nudges the process forward.

Publishing to a package registry: no manual gatekeepers

They wanted the component library to be available via their package registry. What they didn’t want was a human deciding when to publish and what version number to assign. The release process needed to be automated. Enter Semantic Release.

Semantic Release: commit‑driven versioning and end‑to‑end publishing

Semantic Release is a Node.js tool you add to your project (regardless of stack) that performs five essential steps:

Analyze all commits since the last published version
Decide which part of the version to bump (patch, minor, major)
Create the version tag
Publish to the package registry
Generate a changelog from the commit messages

The price of admission is a standardized commit message format. Höller points to the Angular commit message format, which includes:

A type such as fix, feat, refactor, or build
A scope, for example button, accordion, or select
A short summary
An optional body for details and for declaring breaking changes

With those conventions, versioning stops being arbitrary and becomes a property derived from source control history. As Höller put it:

“I cannot make up any random version numbers anymore. This is dictated by the changes that I do.”

Reading semantic versioning correctly

Semantic Release relies on semantic versioning (SemVer):

Patch for bug fixes and small changes
Minor for new features that are backward‑compatible
Major for breaking changes

Höller emphasized that “major” is often misunderstood. It’s not about a big rewrite; it’s about breaking the API for consumers of the library. He also gave examples that clarify the mapping:

A bug fix (“fix …”) increments patch
A feature (“feat …”) increments minor
If the API changes in a breaking way, declare it as a breaking change in the commit body and increment major
A refactor typically doesn’t change behavior; but if it deprecates an old mixin (for example), that deprecation still warrants a new release — a minor bump if there’s no break

This clarity benefits both producers and consumers: It sets expectations and allows automation to do the heavy lifting.

The live demo: a missing style asset becomes a release

Höller’s demo walks through an end‑to‑end release triggered by a small but realistic issue. A simple counter app uses components from the library, but something looks off: the global styles defined by the library don’t show up in the app.

He investigates the library first. The global styles — colors, gradients, and so on — exist and are exported through a barrel file. The problem is that the package does not export the assets in its package configuration. He fixes that by exporting the styles as assets.

The crucial step comes next: the commit message. He classifies the change as a bug fix and describes it accordingly — effectively “add global styles as assets.” He pushes directly to main, which triggers the GitLab pipeline:

Install dependencies
Build the library
Publish

A key detail in the pipeline is artifact handling. The build job outputs the compiled library to a dist folder and exposes it as a pipeline artifact. The release job then reuses that artifact and runs Semantic Release.

The logs tell the story:

Previous tag was 2.4.2
Since then, one commit of type fix was added
Semantic Release decides on a patch bump to 2.4.3
It publishes the package to the registry
It creates release notes based on the commit

The package registry shows the new package and its release entry. On the consumer side, the counter app updates to the new library version. It imports the styles and executes the provided mixin. The visual result appears instantly: the gradient is applied and the buttons match the design system.

This path — from a single corrective change to a published patch and a visible app update — demonstrates “effortless” in practice. No manual version bookkeeping, no ad‑hoc changelog writing, no bespoke steps. The standard commit message is enough to drive the entire process.

Lessons learned: discipline at commit time, relief in day‑to‑day work

Höller is candid about the costs and benefits:

Setup friction is real. He joked that the demo setup cost “50 commits of pain” because deployment is hard.
Version numbers are no longer a negotiation. “I cannot negotiate with anyone — it’s dictated.”
Commit messages require care. Teams must choose the right type and scope, write a precise summary, and declare breaking changes in the body.
The pipeline is unforgiving — in a good way. It will tell you when you’re wrong, especially if you enable commit message linting, which he recommended.
After setup, Semantic Release requires little maintenance and “very often just works,” while nudging teams to avoid breaking changes by default.
Incremental updates beat big‑bang releases. Smaller steps make it easier to discover, isolate, and fix bugs.

“I can update my project step by step — not those large version updates that take forever.”

On the library side, the result is tangible: no God components, solid APIs, clear behavior, Storybook documentation, and design direction provided by dedicated designers.

The pipeline building blocks that matter

From our vantage point, the minimal set of building blocks for effortless versioning looks like this:

A clear architectural boundary for the library

A separate repository for resilience to drive intent and protect scope
Its own release cadence and governance

A strict commit convention

Types like fix, feat, refactor, build
A scope per affected component/module
A meaningful summary
A body for details and for marking breaking changes

A CI pipeline that passes build artifacts forward

An install job
A build job that produces an artifact
A release job that consumes that artifact and runs Semantic Release

Automated dependency maintenance

Renovate to open pull requests for updates

A package registry as the distribution channel

With versions and changelogs visible to consumers

Semantic nuance that pays off

“Major” signals an API break, not a dramatic rewrite. That distinction prevents confusion with stakeholders.
Deprecations are release‑relevant even without a break; treat them as minor increments so consumers get a heads‑up.
The consumer experience matters. A trustworthy registry with consistent SemVer and generated changelogs is a key part of adoption.

Consuming the library: small updates, clear signals

On the consumer side, Höller’s demo models the ideal experience:

A minimal‑risk patch update
An app that updates the dependency
A small integration step (importing and executing the styles mixin)
An immediately visible improvement in the UI

Trust is built on updates that behave as promised. SemVer and changelogs let teams adopt new versions more frequently, reducing risk and giving steady value delivery room to breathe.

Why Semantic Release fits this problem so well

Semantic Release connects the dots in exactly the right places for this use case:

Automation replaces manual decisions about version numbers
A consistent commit language replaces subjective judgment
Releases become reproducible, and consumers gain visibility through changelogs
The bridge from source control to the package registry becomes reliable

Höller also noted the breadth of integrations. Even though Semantic Release is based on Node.js, it supports many registries beyond npm, including Docker Hub and ecosystems like Rust, Python, and Java (through Maven), as well as publishing for Firefox, Chrome, and VS Code extensions. For organizations spanning multiple stacks, that’s a powerful argument for standardizing on one release engine.

Actionable guidance derived from the session

Here’s what teams can apply right away based on “Effortless Versioning”:

Enforce the commit convention — with linting. Semantic Release only works as intended if commit messages are consistent.
Decouple the library from product code. Multi‑repo keeps scope clean and discourages “just one more option” tendencies.
Design the pipeline to reuse the exact build artifact for publishing. Avoid duplicate builds and mismatched outputs.
Turn on Renovate early. A daily trickle of dependency updates beats quarterly upgrade scares.
Decide how you communicate deprecations. Use commit bodies, changelogs, and Storybook to give consumers a clear path.
Teach “major” properly. It means breaking changes for consumers, not necessarily a huge body of work.

Common pitfalls to avoid

Letting one‑off features sneak into the library: The separate repo is there to force deliberation.
Fuzzy ownership: Keep the triad of tech leads, UX, and frontend distinct and accountable.
Manual release steps: Humans are bad at repetitive precision; machines are good at it.
Invisible changes: Without changelogs, consumers guess; with Semantic Release, they know.

Quotes that stick

“Major is not a brand‑new rework of your product. It is about breaking the API.”

“Renovate creates pull requests for you, and very often you just hit merge.”

“The pipeline tells me when I’m wrong — especially if I enable commit message linting.”

These lines capture the culture Höller advocates: intentional commits, heavy automation, and little ego in versioning.

Conclusion: Effortless versioning is a team sport powered by standards

There’s no magic here. “Effortless Versioning” is what happens when you draw the right boundaries (a separate repo), define clear roles (tech leads, UX, frontend), and rely on tools that enforce standards instead of process debt (GitLab CI, Renovate, Semantic Release).

The demo — a missing style asset fixed, a precise fix commit, a clean pipeline, a patch release, and a visibly corrected UI — shows how short the gap from commit to value can be. For teams dealing with long product lifecycles and many contributors, that gap is exactly where automation pays off.

If there’s one idea to carry forward from Stefan Höller’s “Effortless Versioning” at eurofunk Kappacher GmbH, it’s this: Standardize the smallest unit of change — the commit — and the rest (version, tag, release, changelog) can be automated reliably. That’s where the effortlessness comes from — and where quality emerges.

References mentioned in the session

Semantic Versioning (specification)
Semantic Release (project site)
Angular commit message format
Guide for the GitLab registry and its integration

More Tech Talks

More Tech Lead Stories

More Dev Stories