Versioning and Changelog

[Nebnenut]

Hi,

I’d like to start a discussion about introducing versioning and changelog generation in our GitHub repositories.

this would make it easier to evaluate whether updates to the YAML (or other configuration) are necessary. i have skipped a few versions recently and only know what changed because I have been closely following commits and discussions. A structured versioning and changelog process could make this much more transparent and easier to track.

Do you think it would make sense to introduce something like this for this repositories?
Perhaps this could even be automated directly via GitHub?

BR neb

[Oggy512]

+1 from my side.
Well, one could actually also just review and compare the changes made in the code, even if not following the discussions/issues one can identify changes. However, it would of course be way easier if there is a versioning which highlights changes, especiallcy breaking changes.

[kr0ner]

IMO the git history is the best changelog. Since I don't have a feature roadmap or work in sprints, having a changelog will just increase the effort spent on my side with no real value added. Same for releases, since we do not have betas it makes no sense to do major bumps. Breaking changes will always be announced e.g. as it was done for renaming the power consumptions

I can additionally create a "Breaking Change" label

[Oggy512]

Idea:
Could we maybe add a diagnostic sensor, which displays the currently installed Git Branch id? This is not a real versioning, but it Shows the user at least the currently running „version“?
As of writing this post the sensor would show 97d857b, which is in my Point of view a good enough indicator?

[Oggy512]

Lol 😂
I'm currently not following the development too close, since I'm traveling through Vietnam, so I apparently missed that :-D
Well, great 👍🏻

[Oggy512]

Lol, that is exactly what I've added yesterday 😅 version_hash: "c840a54"

It is a random hash that is created in a pre-commit hook

Coming back to this: even with the current version, I do not have a sensor like "config hash". Did you remove this (again)?
Even with the current firmware-update sensor, in my point of view it would be a benefit to show the currently installed version (hash) as separate sensor value.
With that, it would be easier to compare the commits between the currently installed version and the latest online version. One would need to do this manually of course, but that shouldn't be a problem for teccis.

[kr0ner]

it is there ... you need to compare the contents of "version" file in the repo root with "version" file contents you have locally

[Oggy512]

Any chance to change the version file to a yaml?
Should be "version.yaml" and content shoud contain
git_tag: "{version}"
i.e.
git_tag: "16da9d2"

If this can be done, we could include a text_sensor, which shows the version directly on the ESP, see the following code snipped:

substitutions:
  name: esp32thz504
  friendly_name: ESP32-THZ-Controller
  [...]
  entity_room_temperature: "sensor.temperatur_haus_mittel"
  entity_humidity: "sensor.luftfeuchtigkeit_haus_mittel"
  timezone: "Europe/Berlin"
  <<: !include OneESP32ToRuleThemAll/version.yaml

esphome:
  on_boot:
    priority: -100
    then:
      - lambda: |-
          id(${name}_local_version).publish_state("${git_tag}");

text_sensor:
  - platform: template
    name: "Local GIT Tag Version"
    id: ${name}_local_version
    update_interval: never
    entity_category: diagnostic
    icon: mdi:tag-text-outline

which results in:

[kr0ner]

This will make it harder to implement the request multiple people had : to have a binary sensor that tells that github master was updated so that they know there were changes 😉 your approach just wraps static info into a dynamic sensor. Just looking at the file is easier.

But feel free to alter your local yamls to do that :)

this already exists:

substitutions:
  version_hash: !include ../../version

just add this in your own yaml:

esphome:
  on_boot:
    priority: -100
    then:
      - lambda: |-
          id(${name}_local_version).publish_state("${version_hash}");

text_sensor:
  - platform: template
    name: "Local GIT Tag Version"
    id: ${name}_local_version
    update_interval: never
    entity_category: diagnostic
    icon: mdi:tag-text-outline

also I cannot refer to the git hash in the same commit, as the hash gets generated when the commit is finalized. There is no way to call "git log" or similar in esphome build process. So the only thing I can do is to pre-commit change the version to an arbitrary hash that allows to compare.

[Schmidtjanroman]

There would be a benefit for all who marked the Git with a star, we would have it in our news feed when accessing GitHub 🤗

[kr0ner]

ok, that makes sense. I see what I can do

[Oggy512]

Another idea:

Is it possible to include a diagnostic sensor, which compares the currently installed GIT build tag with the latest online tag?
Could be i.e. a binary sensor "Firmware Update available", which shows off if both ids match and shows on, when the version tags differ?

[kr0ner]

there is still some stuff to fix ^^ but i had to merge the "version" file to check if it works :D

[kr0ner]

it works more or less ...

[15:33:24.320][I][update:110]: New version found: c840a54 (Local: 100deb3)

but the sensor is broken ... It worked before when I did not place it in "Configuration"

[Oggy512]

it works more or less ...

[15:33:24.320][I][update:110]: New version found: c840a54 (Local: 100deb3)

but the sensor is broken ... It worked before when I did not place it in "Configuration"

I was wondering, why you put it in configuration?
In my point of view it's more a diagnostic sensor?

[kr0ner]

Cause the Firmware update also sits there 😉

[kr0ner]

#315