General thoughts/propositions/observations.

[benzino77]

Hi there,

I've got many Tasmota devices running at home and other locations. I'm not trying to fix things which are not broken (still have plenty of devices running on v6.x), but sometimes there is new functionallity or setting which can be usefull or there can be the need to implement the same solution (based on Tasmota and automation created in NodeRed), working months or years in one place, in different location.

Yesterday, I was trying to duplicate solution based on Tasmota, MCP23017 and NodeRed in other location. My working solution is based on v6.x so it is a bit rusty. In the new location I decided to go with v9.5 version. Well, it shows up that I could not because mcp23017 driver is reporting its state in different way and my NodeRed flows needs bazillion changes to work with new version. Not a big deal, I switched sources to v6.6.0 tag, compile and I was good to go (especially that I was putting compenents on my bench lab). I'm not complaining, because there is version change on the major position (on the other hand I was not able to find this information - change of MCP230xx driver API - in CHANGELOG.md).

Let's assume that someone find out, that dummy energy monitor sensor was implemented (brilliant idea to tell the truth) and find this solution very interesting. Migrating from older versions (even with the same number on the major posiotion) to one including this functionallity can be really tricky, not only because many things could change (be incompatibile) but also because new options have defaults set to values which can change someone's plans for evening or weekend ;)

Again - I'm not complaining, this is Open Source project and dev team is spending it's own spare time to move this project forward: adding new things and features, new drivers, new options, help other users to solve their problems, etc.

Maybe you (Tasmota Dev Team) could adjust the way new features are implemented and introduced:

• an API change, memory layout change, etc. should change the version major number - there should "bells start ringing" in user head before upgrading from version 9.x to version 10.x
• minor and patch version number changes should be considered "safe" for average user and do not brake compatibility - somewhere between 9.1.0 and 9.5.0, MCP230xx API has changed
• new fatures should have the default value set to be compatiblie with previous versions (those with the same number on major position) - SetOption65 to name one, which was introduced ON (or OFF I should say) by default

Those are just my observations and propositions of changes to (from my perspective) make Tasmota user world even better.

[barbudor]

I understand your point but I think it is not easy especially regarding drivers that may evolve randomly.

somewhere between 9.1.0 and 9.5.0, MCP230xx API has changed

It wouldn't have make sense to change from 9.1.0 to 10.0.0 for just the MCP driver changes or Tasmota would already be at version 950.

Generally the development version is already changing the 4th number every time something changes such as a MQTT message or Settings. Then the changes goes into a release (major/minor).

[benzino77]

I don't have an answer to all questions. I don't have ready solution to address all concerns. You are absolutely right that it's not easy or can lead to very strange situations (Tasmota version 987.64.5), I just wanted to point some "inconveniences" and talk about ... let's say "user experience" (I'm not sure it's right word/term)

Introducing API change in MCP driver could be moved to the new major version or could be covered by SetOptionX - default is old API interface, but if someone need the new functionality/API and find it interesting it can be changed by SetOptionX. Of course I understand that it's not that easy because every SetOptionX consumes memory and leads to situation that there can be SetOption2345 which is unmanageable. Maybe it can be done by introducing something like sensor29 <opt1>,<opt2>,<opt3>? Changes in MCP driver are of course only an example here, but I hope you get a point: be "safe" during update in boundaries of the same major Tasmota version.

Google returns MILLION results to "tasmota" query. There are "Tasmota evangelists" like "dottore" DrZzs, Rob from "The Hook up", digiblurDIY and many, many more which produce dozens of youtube movies, blogs, tools helping people to start using Tasmota - it is a HUGE project which litterally changed people lives. I've got 44 devices running Tasmota in my house, but I do believe there are many users have hundreds of it - people trust Tasmota and using it in a way that probably most of us can't even imagine. They feel safe, because they don't need to expose their devices to the "cloud", they feel safe because they know it is open source and 215 contributors are working on making Tasmota better, they know that even something is not easy to do with Tasmota it will be in the future because it evolves every day, they know that they will find help from community if they find some obstacles or don't understand something. What I'm trying to say is that maybe there is a way to make them feel even safer.