Design discussion: update support in baker

[aliev]

Hi everyone.

I’d like to start a design discussion around one missing feature that, in my opinion, is the last major blocker for calling baker fully competitive and production-ready: project updates.

At this point, baker already has a solid feature set and is stable enough for real usage. However, compared to tools like copier, there is one important capability we still lack the ability to update an existing project when the template changes.

For reference, here is how update works in copier: https://copier.readthedocs.io/en/stable/updating/

There was already an initial attempt to implement something in this direction: #52

And we also discussed earlier that our comparison table doesn’t clearly highlight that baker currently does not support update:
#17

Before jumping into implementation, I’d really like to pause and ask the community:

• Should baker implement an update mechanism similar to copier, or
• Should we design a different approach that better fits baker’s philosophy and architecture?

Some open questions worth discussing:

• Should updates be fully automatic, interactive, or explicitly opt-in per file?
• Do we want to rely on diffs, checksums, annotations in templates, or something else?
• How important is preserving local user changes vs enforcing template evolution?
• Should update be a first-class command, or more of a guided workflow?

My goal with this post is not to push a predefined solution, but to collect ideas, mental models, and prior experience from people who’ve used Copier, Cookiecutter, or similar tools in production.

If you have thoughts, sketches, or even strong opinions please share them.
I believe that a well-designed update mechanism is the last big piece that can take baker to the next level.

Thanks in advance for your feedback!