Compatible where it protects users

01 — The opinion in one sentence

What is in the repository belongs to its users. Switching tools must not change a byte there.

That concerns three things:

• The configuration. pinup's own file is called .pinup.yaml or .pinup.jsonc (also .yml or .json). pinup reads an existing renovate.json, renovate.json5, .renovaterc or .renovaterc.json in the repository root just the same, with the same rules: objects are merged, lists replaced, packageRules concatenated, null clears. Two files at once pinup refuses instead of silently picking one.
• Branch names and titles. Without a setting of their own, branches start with renovate/ and are named as Renovate names them. pinup adopts open branches instead of duplicating them.
• Annotations. A comment such as # renovate: datasource=docker depName=… above a version line works unchanged. # pinup: works too.

02 — The alternative: a clean break

Many tools start with a format of their own. Dependabot has its dependabot.yml, Renovate its renovate.json. That is a good path for a new tool. It can make its language simpler and carries no legacy.

For pinup a clean break would have meant two things. First, a change in around 200 repositories before the first run shows anything at all. Second, no way back. Whoever tries a new tool should be able to switch it off again without cleaning up.

03 — The price

Compatibility is the most expensive opinion in this series.

Someone else's rules, the odd ones included. pinup has to reproduce Renovate's semantics, down to the presets. Where I would have phrased a rule differently, it still stays the way Renovate reads it.

A rebuild without looking at the code. Renovate is AGPL-3.0, pinup Apache-2.0. I adopt the configuration language but read and copy no code. So I ran the pinned Renovate container and rebuilt its behaviour from recorded inputs and outputs. That takes longer than any fork. An early preset library generated from Renovate's presets I replaced with one written in-house in September 2026.

A moving target. Renovate keeps evolving. Every new version can change behaviour, and pinup only notices when I record anew.

04 — The occasion

The switch in September changed no file in any repository. pinup first ran in shadow mode next to Renovate and compared its plans with the open merge requests. The key for that comparison was the branch name. That only worked because both tools produce the same names. Switching over created no duplicate merge request.

Renaming, but as a step of its own

By now the branches in my estate are called pinup/, and the annotations are moving to # pinup:. That does not contradict the opinion; it follows from it. The rename came as a second, separate step, and it lives in the configuration, not in the code.

GitLab cannot rename the source branch of a merge request. So pinup adopts the still-open renovate/ merge requests through branchPrefixOld instead of opening new ones. The annotations are to change only when a plan finds the same dependencies before and after.

05 — The enforcement

Compatibility nobody measures rots quietly. Three mechanisms hold it.

• Configuration parity. Tests compare the resolved configuration with recorded Renovate output, path by path. If two rules swap places, every line of both rules shows up as a difference.
• Deviations with a reason. Where pinup deliberately computes differently, it is on a list of its own. Every entry needs a reason and must hit a real deviation, or the test turns red.
• A fixed yardstick. Measurements are taken against a pinned Renovate version. A new version I have to record anew deliberately. A job that reports it by itself is planned but not built yet.

Conclusion

The cheapest migration is the one nobody notices. pinup pays for it with someone else's rules, a rebuild without looking at the code and a moving target. It still gets its own name, just later and as a step of its own.

Next week: how big an update really is. The stricter label wins. The overview of all parts and the terms that recur are in the opening of the series.