Conversation
There was a problem hiding this comment.
Pull request overview
Updates the “Why Components Exist” narrative in docs/component.md to better motivate the component model by describing common operator lifecycle/status duplication and how components/mutations address it.
Changes:
- Rewrites the “Why Components Exist” section to focus on repeated lifecycle/status patterns across controllers.
- Refines the “files moved into pkg/” discussion to emphasize how feature flags/versioning compound conditional logic.
- Rephrases the benefits of components/mutations to highlight isolated, testable mutations and canonical baseline resources.
| their tests, each one independently readable and testable. Lifecycle behavior (suspension, health reporting, grace | ||
| periods) is handled by the framework, not reimplemented per controller. Adding a feature means adding a file, not | ||
| editing code across the tree. | ||
| Lifecycle behavior (rollout, suspension, status reporting) is handled by the framework, so controllers no longer |
There was a problem hiding this comment.
This section uses different examples for what "lifecycle behavior" includes: earlier it lists "(rollout, suspension, degradation)" (line 12), but here it changes to "(rollout, suspension, status reporting)". To keep terminology consistent and avoid confusing readers about what's meant by lifecycle vs status, consider aligning the examples (or explicitly separating lifecycle actions from status reporting).
| Lifecycle behavior (rollout, suspension, status reporting) is handled by the framework, so controllers no longer | |
| Lifecycle behavior (rollout, suspension, degradation) and status reporting are handled by the framework, so controllers no longer |
| existing one to avoid conflicts. | ||
| This moves files around but doesn't change the underlying problem. Each controller still reimplements the same lifecycle | ||
| patterns in slightly different ways. Version-specific behavior and feature flags compound things further: a probe format | ||
| changes in v1.3, so `pkg/frontend/deployment.go` gains an `if version < "1.3"` branch. A tracing sidecar is |
There was a problem hiding this comment.
The example if version < "1.3" reads like a real comparison, but lexicographic string comparison is incorrect for semver (e.g., "1.10" < "1.3"). Consider rephrasing to a clearly illustrative pseudo-check ("if version is before v1.3") or using a semver-aware comparison in the example to avoid teaching a wrong pattern.
| changes in v1.3, so `pkg/frontend/deployment.go` gains an `if version < "1.3"` branch. A tracing sidecar is | |
| changes in v1.3, so `pkg/frontend/deployment.go` gains an extra branch for versions before v1.3. A tracing sidecar is |
No description provided.