Nicolas De loof

sure, you can use `cli.ProjectFromOptions` to load compose file(s) and interpolate variables, make changes to the compose model, then just use `yaml.Mashall` to get it back into a plain yaml...

`groupXFieldsIntoExtensions` indeed applies the `x-*` reserved prefix logic everywhere, while docker-compose is not that strict. According to the spec https://github.com/compose-spec/compose-spec/blob/master/spec.md#extension > Special extension fields can be of any format as...

Even from a technical point of view we prevented configuration to be applied using the `check` method, this is indeed very disappointing for end-user, and might even let him feel...

We indeed need some separation between the API and the implementation details and dedicated configurators. So far they all live in the same package, an `api` package would make sense...

I agree there's many reason we could benefit a core bump, but on the other side we need to keep compatibility with version used by end-users. I wish we had...

right. Anyway how does core-update impact the need to separate plugin API, which would target an older core ? We still would need to release an old-core implementation plugin for...

My personnal preference would be to define a metadata API for data-bindable components, that would be both supported by JCasC and Stapler (and maybe Structs-plugin) as an alternative to reflection-discovery.

great suggestion. I have no idea if possible to implement within the configuration UI (guess this would require some new hooks directly within the jelly lib), but would be great...

with yaml file merger (https://github.com/jenkinsci/configuration-as-code-plugin/commit/bdf0f0f47fea6d7641fc9741113ac4293409fee7) it should be possible to keep the current yaml data in memory while (re)parsing configuration, and then detect such removals.

In a perfect world we could compare `export` with incoming config to compute a delta, but we are far from being able to generate a valid export. So hard for...