🏷️ The simple approach to versioning

The biggest barrier to starting something is an unwillingness to start simple. Let's use versioning as an example. The natural tendency is to think that all software components need their own version, which can be a daunting task to implement, track, and manage. However, until a team is large enough to have multiple groups dedicated to different tasks, instead put everything in a monorepo and use a single version for everything. Not every component needs to be released with every version, only the ones that have changed. There are several advantages:

• There is a single changelog to review.
• It is easy to coordinate things - components of the same version should work well together.
• Much easier to use AI to execute tasks that involve multiple components. If there are several repos, you are always fighting security checks when crossing repos (at least in Claude Code).
• It is easy and simple.

"But!!!," you say, "The versions won't always be sequential, some will be skipped for various components!!!" Why does this matter? If it bothers you, release every component for every version. Automation can easily do this.

The resulting changelog looks something like this:

2026-03-06 v3.0.18

[Server]

- Fix mongo iterator stopping on decode errors instead of skipping bad documents
  Add bson truncate tags to all int fields to handle float64 values from
  JavaScript

[GW]

- Improve response of Modbus polling.

[Portal]

- Add UI for e2e test status.

2026-03-06 v3.0.17

[Server]

- Log rule count each processing cycle to aid debugging

2026-03-06 v3.0.16

[E2E testing]

- Improved ntfy error messages to include response body for easier debugging.
- Reduced log noise: only log pump and cycle mirror state changes instead of
  continuous tank level.
- Added logging of test status on initial check and state changes.

Start simple, and add complexity when there is a need.