Changelog Policy

Reference for how computationally meaningful changes are classified and communicated in the current release.

This page defines how Licklider communicates changes that may alter the meaning or reproducibility of computed outputs.

What counts as a breaking change

A change should be treated as breaking if the same input could produce a different numerical or decision-relevant result under the new behavior.

Examples include:

  • default test-selection changes
  • effect-size formula changes
  • interval-computation changes
  • outlier-sensitivity decision-policy changes
  • versioned rule changes that alter interpretation-relevant output

What does not automatically count as breaking

Not every product change is a computational breaking change.

Examples that may be non-breaking include:

  • wording improvements
  • navigation changes
  • documentation clarification
  • presentational UI refinements that do not alter the underlying result

Communication expectations

Breaking computational changes should never be treated as silent background maintenance.

Users should be able to understand:

  • that behavior changed
  • what kind of result may be affected
  • whether the change affects interpretation, reproducibility, or both
  • where to find the applicable version context

Breaking or potentially interpretation-relevant changes should be communicated through a combination of:

  • release notes
  • product-facing change summaries where appropriate
  • artifact or audit metadata when re-analysis context matters

Conservative reading rule

If a change could alter the result for the same data, treat it as a changelog event that deserves explicit communication even if the product workflow looks similar on the surface.