mirror of
https://github.com/Akkudoktor-EOS/EOS.git
synced 2026-01-01 08:16:18 +00:00
58d70e417b
Adapters for Home Assistant and NodeRED integration are added. Akkudoktor-EOS can now be run as Home Assistant add-on and standalone. As Home Assistant add-on EOS uses ingress to fully integrate the EOSdash dashboard in Home Assistant. The fix includes several bug fixes that are not directly related to the adapter implementation but are necessary to keep EOS running properly and to test and document the changes. * fix: development version scheme The development versioning scheme is adaptet to fit to docker and home assistant expectations. The new scheme is x.y.z and x.y.z.dev<hash>. Hash is only digits as expected by home assistant. Development version is appended by .dev as expected by docker. * fix: use mean value in interval on resampling for array When downsampling data use the mean value of all values within the new sampling interval. * fix: default battery ev soc and appliance wh Make the genetic simulation return default values for the battery SoC, electric vehicle SoC and appliance load if these assets are not used. * fix: import json string Strip outer quotes from JSON strings on import to be compliant to json.loads() expectation. * fix: default interval definition for import data Default interval must be defined in lowercase human definition to be accepted by pendulum. * fix: clearoutside schema change * feat: add adapters for integrations Adapters for Home Assistant and NodeRED integration are added. Akkudoktor-EOS can now be run as Home Assistant add-on and standalone. As Home Assistant add-on EOS uses ingress to fully integrate the EOSdash dashboard in Home Assistant. * feat: allow eos to be started with root permissions and drop priviledges Home assistant starts all add-ons with root permissions. Eos now drops root permissions if an applicable user is defined by paramter --run_as_user. The docker image defines the user eos to be used. * feat: make eos supervise and monitor EOSdash Eos now not only starts EOSdash but also monitors EOSdash during runtime and restarts EOSdash on fault. EOSdash logging is captured by EOS and forwarded to the EOS log to provide better visibility. * feat: add duration to string conversion Make to_duration to also return the duration as string on request. * chore: Use info logging to report missing optimization parameters In parameter preparation for automatic optimization an error was logged for missing paramters. Log is now down using the info level. * chore: make EOSdash use the EOS data directory for file import/ export EOSdash use the EOS data directory for file import/ export by default. This allows to use the configuration import/ export function also within docker images. * chore: improve EOSdash config tab display Improve display of JSON code and add more forms for config value update. * chore: make docker image file system layout similar to home assistant Only use /data directory for persistent data. This is handled as a docker volume. The /data volume is mapped to ~/.local/share/net.akkudoktor.eos if using docker compose. * chore: add home assistant add-on development environment Add VSCode devcontainer and task definition for home assistant add-on development. * chore: improve documentation
148 lines
3.5 KiB
Markdown
148 lines
3.5 KiB
Markdown
% SPDX-License-Identifier: Apache-2.0
|
||
(release-page)=
|
||
|
||
# Release Process
|
||
|
||
This document describes how to prepare and publish a new release **via a Pull Request from a fork**,
|
||
and how to set a **development version** after the release.
|
||
|
||
## ✅ Overview of the Process
|
||
|
||
| Step | Actor | Action |
|
||
|------|-------------|--------|
|
||
| 1 | Contributor | Prepare a release branch **in your fork** |
|
||
| 2 | Contributor | Open a **Pull Request to upstream** (`Akkudoktor-EOS/EOS`) |
|
||
| 3 | Maintainer | Review and **merge the release PR** |
|
||
| 4 | CI | Create the **GitHub Release and tag** |
|
||
| 5 | CI | Set the **development version marker** via a follow-up PR |
|
||
|
||
## 🔄 Detailed Workflow
|
||
|
||
### 1️⃣ Contributor: Prepare the Release in Your Fork
|
||
|
||
#### Clone and sync your fork
|
||
|
||
```bash
|
||
git clone https://github.com/<your-username>/EOS
|
||
cd EOS
|
||
git remote add eos https://github.com/Akkudoktor-EOS/EOS
|
||
|
||
git fetch eos
|
||
git checkout main
|
||
git pull eos main
|
||
````
|
||
|
||
#### Create the release branch
|
||
|
||
```bash
|
||
git checkout -b release/vX.Y.Z
|
||
```
|
||
|
||
#### Bump the version information
|
||
|
||
Set `__version__` in src/akkudoktoreos/core/version.py
|
||
|
||
```python
|
||
__version__ = 0.3.0
|
||
```
|
||
|
||
Prepare version by updating versioned files, e.g.:
|
||
|
||
- config.yaml
|
||
|
||
and the generated documentation:
|
||
|
||
```bash
|
||
make prepare-version
|
||
```
|
||
|
||
Check the changes by:
|
||
|
||
```bash
|
||
make test-version
|
||
```
|
||
|
||
#### Create a new CHANGELOG.md entry
|
||
|
||
Edit CHANGELOG.md
|
||
|
||
#### Create the new release commit
|
||
|
||
Add all the changed version files and all other changes to the commit.
|
||
|
||
```bash
|
||
git add src/akkudoktoreos/core/version.py CHANGELOG.md ...
|
||
git commit -s -m "chore: Prepare Release v0.3.0"
|
||
```
|
||
|
||
#### Push the branch to your fork
|
||
|
||
```bash
|
||
git push --set-upstream origin release/v0.3.0
|
||
```
|
||
|
||
### 2️⃣ Contributor: Open the Release Preparation Pull Request
|
||
|
||
| From | To |
|
||
| ------------------------------------ | ------------------------- |
|
||
| `<your-username>/EOS:release/vX.Y.Z` | `Akkudoktor-EOS/EOS:main` |
|
||
|
||
**PR Title:**
|
||
|
||
```text
|
||
chore: prepare release vX.Y.Z
|
||
```
|
||
|
||
**PR Description Template:**
|
||
|
||
```markdown
|
||
## Prepare Release vX.Y.Z
|
||
|
||
This pull request prepares release **vX.Y.Z**.
|
||
|
||
### Changes
|
||
- Version bump
|
||
- Changelog update
|
||
|
||
### Changelog Summary
|
||
<!-- Copy key highlights from CHANGELOG.md here -->
|
||
|
||
See `CHANGELOG.md` for full details.
|
||
```
|
||
|
||
### 3️⃣ Maintainer: Review and Merge the Release PR
|
||
|
||
**Review Checklist:**
|
||
|
||
- ✅ Only version files and `CHANGELOG.md` are modified
|
||
- ✅ Version numbers are consistent
|
||
- ✅ Changelog is complete and properly formatted
|
||
- ✅ No unrelated changes are included
|
||
|
||
**Merge Strategy:**
|
||
|
||
- Prefer **Merge Commit** (or **Squash Merge**, per project preference)
|
||
- Use commit message: `chore: Prepare Release vX.Y.Z`
|
||
|
||
### 4️⃣ CI: Publish the GitHub Release
|
||
|
||
The new release will automatically be published by the GitHub CI action.
|
||
|
||
See `.github/workflwows/bump-version.yml`for details.
|
||
|
||
### 5️⃣ CI: Prepare the Development Version Marker
|
||
|
||
The development version marker `.dev` will automatically be set by the GitHub CI action.
|
||
|
||
See `.github/workflwows/bump-version.yml`for details.
|
||
|
||
## ✅ Quick Reference
|
||
|
||
| Step | Actor | Action |
|
||
| ---- | ----- | ------ |
|
||
| **1. Prepare release branch** | Contributor | Bump version & changelog |
|
||
| **2. Open release PR** | Contributor | Submit release for review |
|
||
| **3. Review & merge release PR** | Maintainer | Finalize changes into `main` |
|
||
| **4. Publish GitHub Release** | CI | Create tag & notify users |
|
||
| **5. Prepare development version branch** | CI | Set development marker |
|