Skip to content

Conversation

@sneridagh
Copy link
Member

@davisagli @ericof

This is a small change, but it can be annoying, as soon we would start using the catalog in core (because everybody would have to add this file in their projects, otherwise, the build will fail when it finds a "catalog:" entry.

So, I have two proposals I already mentioned to you before.

The first one, is that we need to streamline the "re-generation" of projects, by saving the data somewhere (cookiecutter replay file would be ok). We tap into it, we assign a known place in the generated project, that we later re-read on demand, replay cookieplone with it. We could use repoplone for it, or just cookieplone command line.

Second, is that maybe we can write "upgrade steps" for cookieplone? Given a local version of the generated files (based on date, for example), we run all the pending upgrade steps, in a GS fashion. make upgrade, or uvx repoplone upgrade What do you think?

@sneridagh
Copy link
Member Author

@ericof @davisagli I'd like to meet and talk about this proposal and cookieplone roadmap in general.

@sneridagh sneridagh merged commit 060fbeb into main Jan 12, 2026
39 checks passed
@sneridagh sneridagh deleted the catalogsupport branch January 12, 2026 07:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants