Kompatibel, wo es Nutzer schützt

01 — Die Meinung in einem Satz

Was im Repository steht, gehört den Nutzern. Ein Wechsel des Werkzeugs darf dort kein Byte ändern.

Das betrifft drei Dinge:

• Die Konfiguration. pinups eigene Datei heißt .pinup.yaml oder .pinup.jsonc (auch .yml oder .json). Eine vorhandene renovate.json, renovate.json5, .renovaterc oder .renovaterc.json im Wurzelverzeichnis liest pinup genauso, mit denselben Regeln: Objekte werden zusammengeführt, Listen ersetzt, packageRules aneinandergehängt, null löscht. Zwei Dateien zugleich lehnt pinup ab, statt still eine zu wählen.
• Branch-Namen und Titel. Ohne eigene Einstellung beginnen Branches mit renovate/ und heißen wie bei Renovate. Offene Branches übernimmt pinup, statt sie zu verdoppeln.
• Annotationen. Ein Kommentar wie # renovate: datasource=docker depName=… über einer Versionszeile funktioniert unverändert. # pinup: geht auch.

02 — Die Alternative: ein sauberer Schnitt

Viele Werkzeuge beginnen mit einem eigenen Format. Dependabot hat seine dependabot.yml, Renovate seine renovate.json. Das ist ein guter Weg für ein neues Werkzeug. Es kann seine Sprache einfacher bauen und muss keine Altlasten tragen.

Für pinup hätte ein sauberer Schnitt zwei Dinge bedeutet. Erstens eine Umstellung in rund 200 Repositories, bevor der erste Lauf überhaupt etwas zeigt. Zweitens keinen Weg zurück. Wer ein neues Werkzeug ausprobiert, soll es auch wieder abschalten können, ohne aufzuräumen.

03 — Der Preis

Kompatibilität ist die teuerste Meinung in dieser Serie.

Fremde Regeln, auch die seltsamen. pinup muss Renovates Semantik nachbilden, bis in die Presets. Wo ich eine Regel anders formuliert hätte, bleibt sie trotzdem so, wie Renovate sie liest.

Nachbau ohne Blick in den Code. Renovate steht unter AGPL-3.0, pinup unter Apache-2.0. Ich übernehme die Konfigurationssprache, lese und kopiere aber keinen Code. Also habe ich den gepinnten Renovate-Container ausgeführt und sein Verhalten aus aufgezeichneten Ein- und Ausgaben nachgebaut. Das dauert länger als jeder Fork. Eine frühe Preset-Bibliothek, die aus Renovates Presets erzeugt war, habe ich im September 2026 durch eine selbst geschriebene ersetzt.

Ein Ziel, das sich bewegt. Renovate entwickelt sich weiter. Jede neue Version kann das Verhalten ändern, und pinup merkt es erst, wenn ich neu aufzeichne.

04 — Der Anlass

Der Umstieg im September hat in keinem Repository eine Datei geändert. pinup lief zuerst im Shadow-Modus neben Renovate und verglich seine Pläne mit den offenen Merge-Requests. Der Schlüssel für diesen Vergleich war der Branch-Name. Das ging nur, weil beide Werkzeuge dieselben Namen erzeugen. Beim Umschalten entstand kein doppelter Merge-Request.

Umbenennen, aber als eigener Schritt

Inzwischen heißen die Branches in meinem Bestand pinup/, und die Annotationen wechseln zu # pinup:. Das ist kein Widerspruch zur Meinung, sondern ihre Folge. Die Umbenennung kam als zweiter, eigener Schritt, und sie steht in der Konfiguration, nicht im Code.

GitLab kann den Quell-Branch eines Merge-Requests nicht umbenennen. Deshalb übernimmt pinup über branchPrefixOld die noch offenen renovate/-Merge-Requests, statt neue zu öffnen. Die Annotationen sollen nur wechseln, wenn ein Plan vorher und nachher dieselben Abhängigkeiten findet.

05 — Die Durchsetzung

Kompatibilität, die man nicht misst, verrottet leise. Drei Mechanismen halten sie.

• Parität der Konfiguration. Tests vergleichen die aufgelöste Konfiguration mit aufgezeichneten Renovate-Ausgaben, Pfad für Pfad. Tauschen zwei Regeln die Reihenfolge, erscheint jede Zeile beider Regeln als Abweichung.
• Abweichungen mit Begründung. Wo pinup bewusst anders rechnet, steht das in einer eigenen Liste. Jeder Eintrag braucht eine Begründung und muss eine echte Abweichung treffen, sonst wird der Test rot.
• Ein fester Maßstab. Gemessen wird gegen eine gepinnte Renovate-Version. Eine neue Version muss ich bewusst neu aufzeichnen. Ein Job, der das von selbst meldet, ist geplant, aber noch nicht gebaut.

Fazit

Die billigste Migration ist die, die niemand bemerkt. Dafür zahlt pinup mit fremden Regeln, einem Nachbau ohne Blick in den Code und einem Ziel, das sich bewegt. Den eigenen Namen bekommt es trotzdem, nur später und als eigener Schritt.

Nächste Woche geht es um die Frage, wie groß ein Update wirklich ist: Das strengere Label gewinnt. Die Übersicht aller Teile und die Begriffe, die öfter vorkommen, stehen im Auftakt der Serie.