Config files declare their GitTally version (v0.9.18)

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
mhoennig
2026-08-29 10:18:21 +02:00
co-authored by Claude Opus 5
parent 8608170f5b
commit 0428cf6737
2 changed files with 18 additions and 1 deletions
+1 -1
View File
@@ -12,7 +12,7 @@ group = "de.hoennig"
// bump at least the patch version for every deployment — and only then, not per commit —
// so the UI footer (BuildProperties), --version and the release notes identify what is
// actually running; a deployment bundles whatever was committed since the last one
version = "0.9.17"
version = "0.9.18"
java {
toolchain {
@@ -7,6 +7,23 @@
<div th:replace="~{fragments :: nav(${view})}"></div>
<div class="panel release-notes">
<h2>v0.9.18 <span class="muted">— 2026-08-29</span></h2>
<ul>
<li>A configuration file can declare which GitTally it is written for, so a version
that renames or drops a key says so instead of silently ignoring what it no longer
understands:
<code>gitTally: { version: { since: "0.9.18", below: "2.0" } }</code>.
<code>since</code> is enforced — both against a GitTally that is too old and
against a file written before the version in which the configuration format last
changed incompatibly, which GitTally knows about itself. <code>below</code> is a
release marker and only warns, so an unmaintained value can never stop a build.</li>
<li>The reach follows the file: the machine and project configuration abort the start
naming the file and the way back, an incompatible configuration committed on a
branch fails only that branch's builds. A file that declares nothing keeps working,
and <code>gittally init</code> writes the current version into the config it
generates.</li>
</ul>
<h2>v0.9.17 <span class="muted">— 2026-08-29</span></h2>
<ul>
<li><strong>Fixed:</strong> a page left in the background — a phone tab switched away