That would not solve the problem.
By choosing only major updates you miss all bug fixes.
By choosing only minor updates you will still see many updates.
Major releases are for new features, minor are for bug fixes. All software releases work this way.
The solution is simple. Only update when you need to or want to. It’s not rocket surgery.
The question was: Are breaking changes or depreciations ever found on a minor release?
1 Like
No.
Major releases are for new features, minor are for bug fixes. All software releases work this way.
All software does not work this way. This is not true for semantic versioning:
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes
- MINOR version when you add functionality in a backward compatible manner
- PATCH version when you make backward compatible bug fixes
The problem (here, not generally) is that ESPHome doesn’t actually follow semantic versioning. Judging by their versions, they follow a monthly schedule just like HA.
It sounds like @catacluj is looking just to update when there are breaking API changes. However, @tom_l is still right that you’ll miss bug fixes this way.
I think you should just find some method of hiding/showing updates on whatever schedule fits you best. Perhaps there is some way to automatically disable/hide and then show entities. You also could try automatically skipping updates and then just check/unskip your skipped updates on some schedule.
While Semantic Versioning may be defined in a certain way, and developers may or may not follow it closely, it is not true that “All software releases work this way.”
I am a Firmware engineer and follow the cycle I proposed (let’s call it the “Cat” cycle if never else has done it before 
), as we couldn’t allow bugs in the “wild” (as much as possible).
Only N.0.0 are ever released, free of known bugs/issues, with all the new functionality and/or breaking changes.
All work just before the release of N.0.0 was to test and fix the bugs introduced by new features in N-1.z.w. which were for testing/enthusiasts only and had to be (easily) requested by any outside “enthusiasts/willing testers”.
Please don’t start with “there are always bugs”; we know that; there’s a difference between the potential/number/severity of bugs when really tested/fixed and the release-now/fix-later methodology.
The “Cat” development cycle works really well and customers are happy.
Maybe other companies use it too, but it’s a competitive advantage that they are not willing to share.
While it’s true that “many” users in the wild may catch bugs faster than fewer “people”, let’s not forget that that’s what Test Engineers are for (I know; I was one, and sometimes still play the role), and good ones, in well run companies, write automated tests WHILE developers develop such that by the time the features are finished there’s very little lag.
Cat
How well would your non standard firmware update method scale to the second biggest project on github with many hundreds of contributors and a deliberately chosen monthly update cycle?
Not well I suspect.
For better or worse, at the moment the developers have chosen a monthly update cycle to ensure rapid progress.
You’ve made your point that you are not happy with this.
You have been given many options to alleviate the stress this causes you.
Rather than continuing to bang your head against the wall, try implementing one of them. See if I helps.
Maybe the release cycle will be changed, maybe it won’t. Either way your situation should improve.
…and if it gets stretched out, we will have more people complaining that they have to wait too long for new functionality to be introduced.
You can never keep everyone happy at the same time, but I think complaining that the releases are too often is just insane. The updates can always be ignored by those that can’t be bothered updating.
2 Likes
I appreciate the helpful answers (not all were, and some were somewhat contradictory) and I feel the community is where such proposals can be made and discussed.
We don’t always get so many updates - so often, but if we find a solution, why not? That’s what discussions are for.
I feel that some of you are (some nicely) asking me to stop. Why? Some level of workarounds have been proposed, but I believe there is no solution yet.
Since I currently have no choice, I will have to follow some of the given advice, but would you ask me to not propose change when I think it’s good, and the only counter-argument I see, is that “that’s how it’s done”; not even “that’s how it’s always been done” (not that that would be any better, see the wheel below).
I proposed something that:
- @tom_l, while change can be scary, it is the engine of progress. Before CI/CD there was no CI/CD. Long ago there was Waterfall (still used, I think, in some big places). Things change all the time. People thought the inventor of the wheel was crazy. Can you think of some reasons why my proposal wouldn’t work? Whatever is “at the moment” will not change if not challenged.
- @sparkydave I think nobody (I know that’s impossible, let’s say virtually) would have reason to complain about “my cycle”, because new features (buggy as they may be, but important to some) would still be obtainable as soon as available, either by request or by choosing a higher/lower update level (if they were made available).
Almost everybody keeps saying updates can be ignored. I think not easily, not tidily, not without more effort/risk than should be needed.
How do you keep track/remember what was in updates weeks ago, if/when they keep coming every few days and may have dependencies that one would also have to keep track of?
Actually it’s very easy to just let the update sit there in the Settings section of HA and you just don’t click on it. Why would it be of concern? That list of updates could be 100 long and not affect your dashboards in any way. Then when you feel like it, they are all there waiting for you to pick which ones to update.
Oh no!
I meant easily AND tidily AND without risk.
Is your example supposed to demonstrate that there’s never risk?
That it’s tidy to have to check every day if the numbers/sources of notifications have changed, because you masked some, but not all, because of many possible reasons?
If you think it does (demonstrate), then I can’t demonstrate otherwise to you.
1 Like
Easy? Yes, just don’t click update.
Tidy? Yes, since the update notification sits in your Settings area and does not impead on your dashboards at all.
Without risk? That comes down to the particular update, which in fact basically stands in the face of your entire argument since any ‘risky’ update would only be a risk if you don’t update, say if there was a security hole. In that case you would want to update as soon as possible. If you think an update is risky to proceed with, I’d say this is very unlikely with ESPhome since the updates (unless an accidental bug is introduced, unlikely) only affect the particular ESPhome component that your device uses. IE: If I update a downlight and the ESPhome update has new feature regarding a temperature sensor, nothing actually changes on the downlight.
No one is making you check for updates daily. This should not be a high cause of concern in your life. Go and enjoy yourself and check for updates when you are bored.
2 Likes
You are sparky 
And I mean that in a good way.
If only every good thing had an advocate like you…
HA used to update every 3 weeks, so they did stretch it to monthly. (I know the thread is about esphome, not HA, but just sayin’)
Afaik the last security update (fixing some upstream bug) was (somewhere) in ESPHome 1.15 in the year 2020. 
Since then all updates are feature updates, like shipped monthly and on top bug fixes for that. 
Personally I have the update notifications disabled because it is just not practical for ~100 esphome nodes. 
I do “regular” updates myself every few month - because I see no urgency in feature updates. 
Also I hope/expect that when a critical/security update get’s rolled out that HA actually uses the “repair” channel to “warn” about that independently from the (for me disabled) update notification channel. 
I think you are wrong. It can be done easily, tidily and if you take into account that over the last 3 years there were no security bugs discovered (and fixed) it should be even a low effort/risk for you 
But as always: From great power comes great responsibility! 
Welcome to the rabbit hole 
Long story short: You don’t need to - in case there is no security updates you just don’t need to. And if you skipped a month, or two or three you just update to the latest and don’t need to keep track of old versions (just don’t forget to read all intermediate change logs and pay special attention to breaking changes!) 
3 Likes
I don’t find the binary option to ignore updates to be either good UX or good security practice. The issue is less that the project itself is being updated regularly, and more with the end-user experience of applying updates so frequently. This is an issue across the entire Home Assistant ecosystem, though the pain is felt most acutely with ESPHome due to the volume of devices many people deploy.
Why not have the ability to either snooze updates or only be notified of updates where the patch number is higher than X? Or perhaps only notify of the most recent prior-month patch version when a new month’s .0 version comes out.
This way there would be fewer updates to apply for those who aren’t willing or able to invest the time to be on the bleeding edge. It also would not put users in the position of having to choose between remembering to go back to find and apply updates OR going for so long without updates that many devices require extensive research to get functional again when a critical issue comes up.
1 Like
@nickrout My “complaint” was because of updates every few days. Like 3. Could have been a few more, as I did try to delay a little, just in case, then updated, then next day there was another update.
@orange-assistant I don’t think you can state that just because things went OK for you (and so many others) with ignoring updates they will continue to be so. And I find it hard to believe that none of the libraries used had any security update in the 3 years. Luckily, our security has many layers and nothing happens when one breaks but that doesn’t mean it’s OK to keep letting them break, one by one.
@TheWanderingTurkey I’m glad I’m not the only one; thank you.
Yeah, it is hard to hit the happy place between a quickly moving software project on the one hand and peace and quiet on the other. I am sympathetic, but I also like the rate of new features and fixes.
@nickrout Come on! Looking at the release history here https://github.com/esphome/esphome/releases/ I can’t see dates, but there are four stamped “2 weeks ago”, one “3 weeks ago”, and another “1 week ago”. That makes SIX within a two weeks period (give or take)!
Is that really what you want?