detekt Baseline Regeneration — which one?
Teams already using detekt need change awareness that baseline matching can drift after source-location and signature fixes, so some upgrades require deliberate baseline regeneration rather than a drop-in version bump.
Blockers
- breaking_change_in: package/detekt-1-23-8 → format/detekt-baseline
- breaking_change_in: package/detekt-2-0-0-alpha-2 → format/detekt-baseline
Who this is for
- monorepo
- small-team
Candidates
Upgrade to current stable detekt and regenerate the baseline in the same change
detekt is open source, so there is no official product pricing to compare; focus on release and migration behavior instead. As of 2026-04-08, GitHub marks `v1.23.8` as the latest stable release, published on 2025-02-20, and its release notes say it is built against Kotlin `2.0.21`. detekt's migration guide explicitly says a KDoc-related location fix caused some users to need to recreate their baseline because findings no longer matched prior baseline entries. The same changelog history also warns that text-location improvements can cause unexpected baseline-file changes, so baseline regeneration should be treated as a normal part of upgrades that touch reported locations or finding signatures.
When to choose
Use this when you want the latest stable 1.x fixes and can tolerate a controlled baseline diff in the same PR. This is the safest default if your team depends on baselines in CI, because it converts silent mismatch risk into an explicit reviewed regeneration step.
Tradeoffs
You stay on the current stable branch and avoid stale tooling, but you must review baseline churn and accept that suppression history may move even when code behavior did not.
Cautions
Do not treat baseline drift as a regression by default; detekt documents that location and signature fixes can invalidate old baseline entries. If you use a shared root baseline in a multi-module Gradle build, regenerate with the same config and source scope you use in CI.
Pin the current detekt version until a scheduled baseline refresh window
This option minimizes immediate churn by freezing on the version whose baseline already matches your current findings. As of 2026-04-08, the stable line is still `1.23.8`, while detekt docs also expose `2.0.0-alpha.2` versioned documentation, which signals that future migration surface is still moving. detekt's documented history shows more than one baseline-affecting change, including KDoc location fixes and older text-location corrections. Pinning is therefore reasonable if baseline stability is more important than taking every patch immediately.
When to choose
Use this when CI noise, branch churn, or a release freeze makes baseline regeneration expensive right now. The decisive factor is whether your team can schedule one deliberate lint-maintenance window instead of absorbing baseline drift during feature work.
Tradeoffs
You avoid surprise diffs in the short term, but you accumulate upgrade debt and postpone toolchain compatibility updates from newer detekt releases.
Cautions
Pinning should be time-boxed. If your Kotlin, AGP, or Gradle versions move forward, delayed detekt upgrades can turn one baseline refresh into a broader compatibility migration.
Evaluate detekt 2.0 alphas only on a disposable baseline
detekt docs currently publish versioned documentation up to `2.0.0-alpha.2`, while the GitHub releases page shows `2.0.0-alpha.1` as a pre-release and `1.23.8` as the latest stable release. That means 2.0 is not the conservative path for teams that need stable baseline continuity. Because detekt has already documented baseline breakage from location and signature fixes on earlier lines, alpha adoption should assume additional baseline churn rather than preserving an old baseline. This makes 2.0 suitable for evaluation branches, not for a silent patch-style rollout into an established baseline workflow.
When to choose
Use this only if you are actively validating detekt 2.0 compatibility and can throw away or regenerate the baseline without process friction. The decisive factor is whether your goal is evaluation of future tooling, not immediate stability.
Tradeoffs
You get earlier visibility into upcoming detekt changes, but you accept pre-release risk and extra migration work.
Cautions
Do not reuse a long-lived production baseline unchanged when trialing 2.0 alphas. Keep the experiment isolated so location or signature changes do not pollute your main suppression history.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "detekt Baseline Regeneration — which one?"