Repositories, releases and tooling
There is the module: (url) and the custom component (url) - the latter referred mostly to as 'beta'. The module contains all the underlying 'library' of functions and the component being the interface for HA.
The release of a 'module' version is through PyPi - as manually doing this would be cumbersome we automated this using GitHub Actions. If there is a new version number in the pyproject.toml and the build is successful it will deploy a new version to test-PyPi. Unfortunately HA is pretty strict about how it interprets and downloads python modules. So some manual tinkering will be involved. This is also why on the Smile side we tend to release to production with a0-9 appended so it is available wider/easier.
The release of the 'custom_component' works by just releasing a new version through GitHub which will be visible to HACS over time (or when refreshed). You can adhere to the 'pre-release' of GitHub which will not show to end-users within HACS unless they ticket the 'show beta versions'.
For release creation you have to be part of the team (i.e. maintainer), as such on the Releases page you'll get the Draft new release button.
So as for the checklist requested, from the above:
- 2. Generate the new version (according to what you set in
manifest.json) - 3. Hit the 'Create new tag' button :)
- 4. Either choose your branch (for an alpha or beta release) or
mainfor a formal release - 5. Hit the 'generate' button to neatly retrieve the information 👍 next, feel free to adjust where necessary, i.e. @bouwew and @CoMPaTech mostly add the
**INTERNAL TESTING**or other clear indications on the release title for alpha and beta releases. - 6. Choose your release wisely; make sure to hit the
pre-releasefor alpha's and beta's. - When checked twice, hit the create release
If for whatever reason you want to undo your release; delete the release (just go to the release by clicking on the title, hit the bin button) and next go to tags and delete the tag. (If you forget the last part, you won't be able to release again as the tag is still there.
For upstreaming (as a native/core component) of HA there is a number of standards to be met. As such the beta custom component already tries to mostly adhere to these (or not fully, see #107 in both repo's). When we joined forces between the Smile (network) and USB teams we 'almost' made it to core with the USB part but unfortunately life got in the way of the main USB developer and the required code quality deviated from the Smile part.
For those familiar with the techniques, the Smile part is now fully typed and up to par with the latest HA demanded ruffing and other linters et such. As per the #107's in both repo's for USB that has diluted over time and we need to get this back on track.
To ensure working with the latest HA-core every component commit is run (besides quality and other checks) through hassfest which will detect any issues upfront. The quality checks do run tests, but at time of writing (dec '23) there are no 'useful' tests except for the conflig_flow validation (which is mandatory for upstreaming to core). Also those have been sitting unchanged since we separated Smile and USB so they are pretty 'stale'.
For the module the quality tests are not there yet, mostly because of a big rewrite was started and a lot of typing/mypy has to be performed before the code is 'up to par' with the (now) selected standard. Aside from testing being the hardest (and most chore) part of developing, first having the code in a good place would be preferable to having tests there. Then again, not having tests available actually prohibits 'non-owners' of the hardware from changing the code. Catch-22 situation :(
Used plugins (where useful for module and beta):
- Flake8
- isort
- markdownlint
- mypy
- prettier
- pylance
- python
- ruff
- VIM (personal preference) Additionally installed Docker, Dev containers, FIX JSON and a number of others, mostly relevant to the Smile and HA-Core development side.
Various web resources on the hardware and the serial protocol