Suggestion versions include date instead of simple sequence number

I’ve noticed that new versions of HA seem to be identified as year.month.sequence.
I’d like to suggest that you use the date instead of an arbitrary sequence number. It would provide a bit of extra information regarding how long it has been since that version has been available, thereby helping to kick the user into getting it installed.

In the very unlikely event that a second update is needed in a single day, you could add a letter, or a .1 or whatever.

Though I suppose that this would require modification of the versioning system, so it probably is too much work of low priority.

What do you mean by sequence number?
The version is already yyyy.mm.sequence (<-- guess it is the last part that you dont like)
So, today, as I’m writing this comment, it is the 5th version of Jan 2023 (i.e.: 2023.1.5)
You can ask for the day as well but in my opinion, it will be much more confusing.

There was the initial version on the 4th of January (as planned), it will be 2023.1.4 in your numbering system, which is already confusing for the first release of the month. When the next one came by it would have been 2023.1.6 for you.
I’ll have the feeling that I missed the 2023.1.5, which will bother me.

I think, the proposal is to use 2023.1.17 instead of 5, given that this version is published on 17th January.

Got it, but isn’t it confusing to go from 2023.1.12 to 2023.1.17 without anything in between?

The SemVer is the mostly used system and it is Major.Minor.Patch with pre-release tag (optional).

Moreover, despite that you could believe you missed non existing versions (12 → 17), the sequence is helping you with the number of release you are behind.

If I’m on 2023.1.2 and current is 2023.1.5, I know that there is 3 patches that have been released

With the proposed numbering, if I’m in 2023.1.9 (formerly 2023.1.2) and I see the 2023.1.17 (formerly 2023.1.5), I don’t know if I missed one release, more, or none. I just know that there is a patch available for 8 days (or more if the current date is Jan 18th.

Finally and it is the most important part: the sensor version is giving you all the details about the release date and much more

source: haio
channel: stable
release_date: 2023-01-17T00:00:00+00:00
release_notes: https://www.home-assistant.io/blog/2023/01/04/release-20231/
release_title: 2023.1: Happy New Year of the voice!
release_description: The first release of the year of the voice! Adding entity aliases for your voice assistants, calendar event editing, progress on Matter, and entity translations improvements!
icon: mdi:package-up
friendly_name: Home Assistant Website
1 Like

Agree, you should know how many releases happened between current and new, using date would eliminate it.

On the other hand, between 2022.12.1 and 2023.1.5, do you know how many versions you are missing? I believe not.

You also have to be aware of the different versions being released
I think currently it is 5 versions that are built and sometimes one built can be delayed 1-2 days,so what version number should they have?

No, you don’t but you know that you missed some releases of December (if any) and, most important, you missed the 6 releases of January (not 17).

I don’t mind about how updates being numbered since the information I could get is mostly of no interest.

Whats more important is to get an idea if an update contains fixes or additional implementations.
Since so coloring the notifications would be nice
Perhaps: fixes = yellow, additionals = green and if contining breaking changes = red

Especially the last category does likley need your attention after having upgraded.

What i meant is that with current system, you cannot get both. Some months, we are releasing 7, sometimes just 3, so it is indicative but not prescriptive.

Sure but in my opinion, the current system, following the SemVer prescriptions is the best.

Every year a major version, with a common thread for the year (2023: year of the voice, 2022: Let’s start streamlining!, …) and a minor version every month.

Then, throughout the month are patches, from none to sometimes 10, like December 2021 if I remember well

it always might contain additional information like:

major.minor.patch (yyyymmdd)
or to be compliant with semver:
major.minor.patch+yyyymmdd

  1. Add version integration and configure the website sensor
  2. Edit your configuration.yaml and add a template sensor
template:
  - sensor:
      - name: home_assistant_website_new_numbering
        state: >
          {% set release_date = as_timestamp(state_attr('sensor.home_assistant_website','release_date')) | timestamp_custom('%d') %}
          {% set current_release = states('sensor.home_assistant_website').split('.') %}
          {% set major = current_release[0] %}
          {% set minor = current_release[1] %}
          {% set patch = current_release[2] %}
          {{ major + '.' + minor + '.' + release_date + ' (aka '+ states('sensor.home_assistant_website') + ')' }}
  1. Create a entity card and add your sensor:
    Result:

2023.1.17 (aka 2023.1.5)

EDIT: or, as template, put this

template:
  - sensor:
      - name: home_assistant_website_new_numbering
        state: >
          {{ states('sensor.home_assistant_website') + ' since ' + as_timestamp(state_attr('sensor.home_assistant_website','release_date')) | timestamp_custom('%B %d, %Y') }}

and get

2023.1.5 since January 17, 2023

1 Like