ESPHome version lock / max_version in addition to min_version

[imitation]

Describe the enhancement

tl,dr: Add max_version or exact_version parameters to the project config section, to force using an older ESPHome environment for building. This maintains project functionality when an ESPHome update would otherwise break the project.

ESPHome already provides some functionality through the min_version option to communicate which functionality is required to compile that specific config. However, as the standard and encouraged behavior is to always keep your ESPHome install updated to the latest version, the more common issues that users run into arises when already existing functionality is changed (eg. in a component), the yaml syntax or structure of the config introduces new requirements or a bug or edge-case behavior is introduced in a new version.
As such, the min_version option often has almost no benefit in making sure projects or components work for as many users as possible.
Instead, the pattern observed when users report a new version breaking their projects is often to blame the user for not reading the changelog, but updating anyway. This is not an entirely unreasonable standpoint, but it's maybe a little too hostile, as, again, users are encouraged to update by e.g. Home Assistant notifications, and would not typically expect an update to break already existing functionality.
I'm sure there are more sophisticated and complex solutions to this, like config migration scripts that automatically suggest modifications when breaking changes are introduces; but what I'd like to suggest, similar to Python's pip > / = / < version management, is a simple max_version or exact_version parameter parameter that a project maintainer can add to instruct the builder to use a specific (older) ESPHome environment to build a project when it is not tested for newer versions, or confirmed to be broken in new versions, therefore enabling a project yaml to stay functional, even when the current version of ESPHome would break it.

Use cases

Distributing project configurations through yaml (or includes), without frustrating users with projects breaking every time ESPHome updates or burdening maintainers with continuously reworking projects that are already fully functional.

Visual examples

No response

Anything else?

Dependency management is an ongoing challenge, especially open-source projects. Python solves it with venvs and pip requirements, Linux distros are moving towards flatpak to manage competing version requirements and unpredictable environments. Imo, ESPHome has grown to a popularity and maturity that similar considerations should be made here as well, even if just with a rudimentary solution for now.

[ssieb]

You can't change the version used to build with. All that setting would do is stop the build saying the version was too new.