Release strategy and versioning w/r/t homeassistant

[MatthewFlamm]

Make a decision on version pinning to home assistant. See #88 (comment) and #88 (comment).

[MatthewFlamm]

One idea is to split this library into two. One houses the automatic scripts, the other has the pytest plug-in.

[bruxy70]

I am not sure I understand the issue. Why can't the releases for HA pre-releases be also marked as a pre-release. Then, I can either decide to install a regular release or beta. Or practically, I can put in my test requirements a specific version.
I use the tests mainly during development, often when HA is in beta (like right now, when they made the calendar event device obsolete, so I updated my integration and would like to ideally run the automated tests). And in the GitHub actions on commits - and that could be during the beta but more often with a regular HA release.

[MatthewFlamm]

One big issue for having beta and non beta releases here that depends on homeassistant is that the version of the extraction code is co mingled with the home assistant version.

The home assistant version is included in the release notes as a short term possibility.

The best solution I think is my last comment, having a separate package for the extraction code that has its own version.

[MatthewFlamm]

An example is to fix #115, which now requires some major changes to the extraction code during a beta release of homeassistant. I have been making a minor release when fixes to the extraction code are made.