Physical text files are not required though.
There was a poll, where most people said they want GUI & Text.
You turn that into: physical files are not needed.
I and many others have said we use a source control system.
That does work with physical files.
Multiple import/export trigger mechanisms could be implemented.
It looks like you only want that for things/items.
For me it would need that on sitemap (or its replacement) and on rules too.
I’m sorry but this shows your absolute inability to read.
The sitemap change was approved by Kai
So far Kai has not been in this discussion and I was not aware this was already approved.
and when.
In every discussion, I only see you(David) as a developer calling the shots.
it could be that you are the spokesperson, yet that was not (still is not) clear for me.
At first I thought I was just ill informed, now I see moderators also not knowing this.
I did not expect Kai to intervene in these discussions the whole moving away from eclipse seems a higher priority right now.
I can understand we need a new way for the sitemap, yet also there I would like a way to configure that outside the gui.
That seems not to have been discussed.
You are so much against change, that’s unbelievable. And you do not even think of a solution (that works!) yourself. Unbelievable. Really.
That’s not true. @Spaceman_Spiff (and others) have done a few proposals. You disagree on the feasibility, yet you can’t claim he is against any change.
I see many people asking for certain functionality to stay.
I see many people making proposals.
As I haven’t seriously developed in Java, I on purposely have not proposed what to do.
I prefer uses say what they need, and developers decide on the how
you as a developer want to decide on the what and you also want user to come up with how. Both are the world upside down for me.
And yes I’m well aware,in opensource stuff is a little more mixed, still I do think that users have a right or better a duty to state what they need.
It seems on top you want a big bang, that really scares me.
We had problems with a too fast move for MQTT.
For MQTT, there still was/is version 1.0 yet the upgrade got screwed up.
There is no one too blame for that, yet we should learn and offer options.
from a developer point I understand that moving, rules, items, sitemaps things all at once is easier.
yet it will make things harder for support, for people to make the move
I have helped many teams over the last 15 years to make smaller upgrades, yet development was harder, yet because teh better support, everyone of the users always moved along. If everything from Openhab 1.x was converted, we would only need to support 2.x
Now you risk that with 3.x you need to upgrade 1.x and 2.x users all at the same time, in a big bang.
As long as people have not moved, you need to manual to stay online and thus also maintain. you have people on the forums that need to know all 3 versions.
That is a support nightmare and that on a forum that does not want to be called support.
You claim that everyone will gladly move and OH3.X will have a lot more users.
yet what I have learned from crossing the chasm theory for IT projects, is that the early and late majority look a lot to the early adopters on what to do. If the early adopters move away because they feel no longer supported, there will be not early majority.
You claim that many in this discussion are against change, yet early adopters, are known to embrace change. If they challenge things, it’s because they fight for a cause.
please get the message.
and yes, I know that right now, for what we are asking, it’s not clear how to do that .
that’s why we need to keep discussing to understand the boundaries of the needs.
I had hoped to go to fosdem and talk to some openhab people in person as it seems we are at the point some F2F discussions can help, unfortunately some family and coderdojo stuff got priority