Of course, but instead of telling people to get random snapshot versions of the various bindings that have received fixes (which may be mutually conflicting), isn’t it a far better user experience to cut a new stable release?
I’m thinking something along the lines of what the KDE project does - one feature release every 4 months and then fixes in the point releases (5.16.1, .2, .3) in the weeks following a feature release.
Thanks - I haven’t tried the snapshots.
The devs have been very busy merging ESH code as well as totally updating the build system. For quite a while the software would not even build.
This is developed mainly by volunteers. If you want more frequent bug fix releases then Home Assistant has that but, in my experience, you lose reliability.
Our current release manager guy doesn’t like multiple different versions in one repository, which would be a requirement for backporting “point” releases. Stupid IMO, because each addon has its own development and breaking changes cycle and semantic versioning would be really nice to have. But that’s how it is.
Cheers, David
Would’ve been very nice if a user could choose binding version in paperUI, so you could easily upgrade a single binding to snapshot release but still be on a M or stable build (this of course with a warning message “at your own risk”) 
It is not guaranteed that using newer versions of bindings on older versions of OH. This might work but might also fail.
There are sometimes other dependencies. OH2 is designed as a monolith, not modular.
It would be a major design decision to change that now. Likely more work than what the are dealing with now.
Home Assistant is quite modular. I am sure there are others. I personally prefer the stability here.
Ask your favorite binding developer to publish the binding to the IoT Marketplace:
(Although I’m not sure what the status is now that ESH has been sourced into openHAB)
Hm, I don’t understand why it would be a major design change? You can still do this manually by putting the snapshot jar file in the right directory, this would just make the job easier through UI…or am I missing something?
Changes made to the core. To support multiple versions of bindings that would require for the latest and greatest version of OH to still expose the same API to the binding as it did X versions back. That greatly increases the maintenance overhead and making changes to the API will become much more involved.
You can sometimes drop a binding of a different version into addons and it will work. But if that binding happens to use part of the core API that changed then the binding will not work.
That’s understandable, that the binding might not work due to changes elsewhere, but that was my intention of the “warning”…use at your own risk. Let the user choose…this would be an “advanced/expert” menu option.
Just a suggestion 
It’s not that simple. Let’s say you’re running OH2.4.0 and BindingX contains a bug which is fixed in the current snapshot version of BindingX. So you install BindingX-2.5.0-Snapshot.
Now the BindingX developer adds a feature which depends on the latest OH2.5.0-Snapshot making the snapshot incompatible with OH2.4.0.
So now you need to keep track of 3 BindingX versions: BindingX-2.4.0, BindingX-2.5.0-Snapshot-backwards-compatible-with-OH2.4.0, and BindingX-2.5.0-Snapshot.
Now let’s add in a couple of milestone releases to the mix and you can see that this get’s complicated real quick.
I think that is understood. But as @lfs_alp5 stated it should be an advanced option at own risk. There is no need of having n versions of binding x or n versions of core as no one needs to guarantee that it works.
What will happen in the worst case? Things won’t work and you go back to the old binding version. That’s it.
Hundreds of forum questions which can’t be answered correctly.
This is a problem of „one version for everything“. If each bundle had it‘s own version we could use 2.4.0 for the version released with OH 2.4. All compatible changes to the binding would be 2.4.1, 2.4.2, … Then an incompatible change is added, that is 2.5.0-pre.1, next is 2.5.0-pre.2, released version then is 2.5.0.
But I‘m 100% sure this will not be available in PaperUI even if this is adopted as versioning scheme because there is no developer for PaperUI.
Let’s say you run OH2.4.0 with a snapshot version of BindingX. It get’s updated and is now incompatible with OH 2.4.0.
Due to some SD card corruption you need to reinstall your OH server but now you can no longer install BindingX-snapshot because it is no longer compatible with your OH2.4.0. You didn’t backup your bindings because you thought that you could install those again via PaperUI.
Now what? 
To be clear, I’m not against this, not at all.
In my opinion the recommendation to run the OH snapshot version is given way too easily. Many people don’t really comprehend what a snapshot build really is. Look at how many topics there are where people install a snapshot version and then “everything is broken” and they aren’t capable of troubleshooting it themselves. They then perform a rollback and they fail at that as well.
I’m much more in favor of running a stable release of OH with selected snapshot bindings when really necessary, e.g. because your Z-Wave device was just added to the database.
There already is such an option. You are free to create your own fork of OH and customize to your heart’s content. Just do not expect support from here.
Heh, I’m fully aware of that, it was just a suggestion.
But it could be available in the replacement for PaperUI that, last I heard, was under development. Perhaps not?
Maybe. But IMO this is more a topic for OH3 than 2.5.