Is it OK to re-build and release binaries for a particular dev version several times? #2523
-
|
I think it is not OK. E.g. I have installed 3.7.3-dev.7 on 10 April 2025. Since then, it has been re-built several times (I am aware of at least two re-builds). So, my EMS-ESP is now showing this:
which is obviously not correct as I am definitely NOT running the latest version (from 13 hours ago). I realise that the changes between 3.7.3-dev.7 from 10 April and 3.7.3-dev.7 from 16 April are minimal, but this can still cause issues. I also realise you don't want to have tens or even hundreds of little dev releases... So perhaps those little changes (like language fix in commit a2aa2dc) could wait for 3.7.3-dev.8? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 7 replies
-
|
I do agree. Changes to the dev branch automatically build a release. I can change it to either be on demand (manually invoking a GitHub Action runner) or automatically by detecting when the version number has increased. This way we have control on when we want to release a new dev release, and the policy here could be either a) when we've bundled up enough improvements and fixes or b) a critical bug is fixed. |
Beta Was this translation helpful? Give feedback.
-
|
I prefere
This makes sure we have only one binary for each dev version. |
Beta Was this translation helpful? Give feedback.
-
|
Could also be manual build and having release number automatically incremented when manual build is triggered. |
Beta Was this translation helpful? Give feedback.
-
|
I'll do the test for a change on the version file, that way we have more control on when we want to make a build. And it's only one line in the GitHub action yaml ;-) Thanks for the tip @VlastiBroucek |
Beta Was this translation helpful? Give feedback.
-
|
I believe change has been implemented in dev.8 so I am closing this discussion. Thanks guys!!! |
Beta Was this translation helpful? Give feedback.
-
|
Sorry to reopen this discussion, but I have noticed that the practice has returned lately. Both dev20 and dev21 have been released at least twice which is rather frustrating. To compound the frustration is the fact that this |
Beta Was this translation helpful? Give feedback.
-
|
it's the same firmware, we were testing the new CI/CD build process that automatially updates the XLS reference files and modbus registeries and could only do this in production. No code changes to the EMS-ESP core. |
Beta Was this translation helpful? Give feedback.
-
|
👍👍👍 |
Beta Was this translation helpful? Give feedback.
-
|
maybe I'll remove the timestamp check for the dev builds if that is causing nervousness? |
Beta Was this translation helpful? Give feedback.
-
|
It's just misleading, not causing nervousness. IMHO, the ideal solution would be to keep timestamp when the last install was done and compare with the last release timestamp. E.g. (fictious numbers), EMS-ESP would see I installed dev.21 on 23/10/25 at 02:00UTC, but the current dev.21 release was released at 24/10/25 at 03:00UTC. So, it would indicate being behind... But hey, it would be making things unnecessary complicated and if this was one off only, I would not probably bother... |
Beta Was this translation helpful? Give feedback.
it's the same firmware, we were testing the new CI/CD build process that automatially updates the XLS reference files and modbus registeries and could only do this in production. No code changes to the EMS-ESP core.