I am as well. Defold as a whole is the product.
What I was referring to was that internally, we have two ways or working with updates.
Smaller (safer) changes are done continuously, on a (possibly) day to day basis (if there was a change). Larger changes are done on a montly basis.
The larger changes are riskier, and needs more thorough testing (hence the Beta period), but ultimately, it should still feel safe to update to the latest version.
Keeping the engine up to date just isnāt very important to me. I stick with whatās been working until it doesnāt - mostly because libraries are kept up to date with the engine.
I have a second computer that I use when updating. I update the engine on that machine and build my current source. If it works, I update my primary dev machine.
So far, I havenāt felt the need to update more often than once or twice a year. The much lower hassle and fewer interruptions are worth postponing updates.
No, definitely I didnāt mean less features! 
More features is definitely the way for Defold, same as with putting things into extensions, these are all good things, just needing more care to please most of the devs 
Thing like a ticket Bjorn created is like a part of this I believe Also things helping devs identify issues that might appear after upgrading, something like warnings in console log, that some function is deprecated, changed etc like e.g. in case of draw3d() function
Always use last, or few releases before last.
Does not have any problems:)
For me big problem can be 1.2.n ā 1.3.0.
Spine breaking change.
I have some old prototypes and project with old spine, and when i want to build it will be very complex.(i do not need it now but in future everything possible)
So if you can support that breaking changes defold version in build server more than 6 month. It can be usefull in some cases.
In other cases, imho it is easy to update engine version to latest.
The engine updates are not frequent and not tiresome. I think the original issue is about updating the editor which can update quite frequently and with no changelog. Perhaps displaying a popup like this:
Engine version: 1.2.4 - up to date
Editor version: 765432 - 765438 available
would clarify the confusion and make the decision whether to update or not clearer. Not all people have fast internet or even fast computers, just unpacking stuff can take some time.
Iāve had some issues here & there with updates. Typically upgrading on Windows was seamless, but once deployed to Android, on rare occassion, crashes would occur in either the engine or (more typically) native extensions.
Luckily, the Defold team is exceptionally fast at reviewing our bug reports and fixing issues!
In an ideal world, Iād have the time to upgrade to each beta version and do on-device testing before the version reaches final release. Until then, itās not a big problem for me to delay releases by a few days while waiting for the engine or native extensions to be fixed.
Iāll add my +1 to the request for having more details in the āupdate is availableā dialog. A changelog or link to view a changelog would be really appreciated.
How common are hotfixes such as this?
Are hotfixes always announced, and what kind of bug would trigger a hotfix?
Yes, we always post about these on the forum. It happens rarely (probably at most once per year).
In this case it was an infrequent crash on 32 bit Android devices due to an off-by-one error in long Lua bytecode diffs. The workaround was to publish one 32bit and 64bit APK, but that is not always possible to do on Google Play, and with enough installs the issue had a significant enough impact that it warranted an immediate fix.
Didnāt 1.3.5 and 1.3.6 have hotfixes too? Or are these a different category?
I would prefer if there were new forum topics about these, as many users wonāt follow threads for released versions.
I would love to suggest, on more beefy new features, like for example the new texture manipulation api in the works, to add some nice examples with different use cases when released (and here the community can help)
Is it possible to āfreezeā old Dockerfiles? If someone were to request a build from a 1-year-old-Defold they could get a build with older SDKs. Would it still ran correctly? They would not get latest and greatest SDKs if they were on old version, it would be their choice.
Weāve chosen the 6 month cutoff point for extender support since that has felt pretty natural for development.
We donāt want to support too many versions on our end since the support burden increases a lot for each SDK.
Also note that that the server is open source, and you can setup your own server to support the SDKās you want.
Oh I love defold for this. Unity was a PITA in dealing with which version do you want to use.
Defold is 100% on the right track IMO.