Skip to Content
Changelog

Changelog

Changelog

This page records noteworthy changes to Coreola itself - the foundation, not your fork of it.

If you are extending Coreola for your product, keep your own changelog (a separate page, a CHANGELOG.md, or release notes). This changelog tracks the template.

The current Coreola version lives in package.json and is surfaced in the app as settings.version (built from VITE_APP_VERSION).

Format

Entries follow a lightweight version of Keep a Changelog :

  • Most recent version at the top.
  • Categories per release: Added / Changed / Fixed / Removed / Deprecated / Security.
  • Each item is one line - link to the relevant docs page or PR for context.

Future releases should add a new version heading above the previous release.

1.0.0 - 2026-05-15

Initial Coreola release.

Added

  • Application shell with authentication, routing, permissions, feature flags, theming, localized navigation, and protected routes.
  • Dashboards for Application and Assessments with KPI rows, operational summaries, and @nivo charts. See UI Patterns -> Dashboards.
  • Customers module with client-side and server-side table strategies, customer details, and segments as saved filters. See Modules -> Customers.
  • Assessments module with list, details, queue, dashboard, findings, evidence requests, and decision workflow. See Modules -> Assessments.
  • Accounts module with users, roles, abilities, and the ability matrix UI. See Modules -> Accounts.
  • Settings module with language, theme, sidebar mode, developer debug translations, and feature flag management. See Modules -> Settings.
  • Profile module with name and email, avatar crop, and password change. See Modules -> Profile.
  • Auth module with sign in, sign up, and send password flows. See Modules -> Auth.
  • Shared component library with documented Coreola components, MUI wrappers, and Storybook stories. See Components.
  • In-app documentation system using localized MDX pages, MDXDoc, and MDXDocAnchors.
  • English and Ukrainian localization with runtime language switching.
  • Mock backend powered by json-server for local development, demos, and generated data.
  • Developer tooling for builds, linting, Storybook, Plop generators, and documentation scaffolding.

Versioning

Coreola follows SemVer :

  • Major (x.0.0) - breaking changes to the surface (route shape, model-hook contracts, public component APIs, theme tokens with names like palette.color.chart).
  • Minor (x.y.0) - new features added without removing existing ones.
  • Patch (x.y.z) - fixes that do not change the public surface.

Upgrading your fork

Most teams fork Coreola once and evolve it. There is no official “upgrade” mechanism - merging upstream changes is a manual reconciliation.

A pragmatic workflow:

  1. Keep a coreola-upstream remote pointing at the original Coreola repo.
  2. Cherry-pick or merge specific commits/PRs you want.
  3. Resolve conflicts in your fork’s branding, routes, and feature modules.
  4. Run npm run build, npm run lint, npm test, and the UI smoke tests.

For larger upstream changes (a new pattern, a refactor of a primitive), consider doing the same change yourself rather than merging - it lets you keep the diff smaller and your fork’s narrative cleaner.

Tracking what is breaking

When a Coreola release is marked breaking, the changelog entry includes:

  • What broke - the old shape and the new one.
  • Why - the reason for the change (often a bug or a tighter contract).
  • Migration - a code-level recipe for adapters.

If you ship Coreola as a product foundation to multiple internal teams, mirror this discipline in your own changelog.

Reporting issues

If you find a bug or have a suggestion for the Coreola template itself, file it against the Coreola repository. Bugs in your fork stay in your fork’s tracker.

Next steps

Last updated on
Scripts