As an industrial user, it is a big hassle to have breaking changes from the software.
Whenever there is a breaking change from software version upgrade that makes current flow non-functional, then the team has to go through lots of QA, and customers will have to invest lots of resources on the breaking change too.
This is a key reason that prevents us from using some software that has frequent breaking changes.
Node-RED itself is excellent to keep things consistent. Dashboard did an excellent job too.
We are trying to migrate to Dashboard 2 from DB1, and we want to minimize the risks. It would be great to minimize breaking changes on DB2.
The avoiding mostly means additional code to create, maintain and it is hard to find a point in time to get rid of. It ends with fastly growing amount of the dead code which at some point start's to affect performance.
We have, which Dashboard 1.0 did not, an extensive nunber of automated tests in place for Dashboard 2.0 to ensure stability. These are run for every change request to the code base, and before any release is published.
We don't have 100% coverage with this, it's almost impossible to, but you can be rest assured it is thoroughly tested, both manually and automatically before any changes are published.
We also have a very quick turn around time for few bugs that are opened too.
DB2 is progressing at an amazing pace but it is still an infant. Personally, I wouldn't yet recommend it for production use.
DB1 is mature and won't change. But it may start to gain security issues.
UIBUILDER is mature and actively maintained and tries to avoid breaking changes and where they are needed, tries to minimise the impact. Helped by the fact that it does not use any dependent front-end frameworks. But it does need a slightly different way of thinking about front-end development (albeit one that is more aligned to other web development styles).
Well of course while we contribute to the dashboard, we always try to avoid breaking changes. But from my experience there are at least a few reasons for breaking changes:
Since dashboard D2 is a pretty young software product that is growing fast, there are from time to time things that aren't really consistent. And then we discuss that in the pull request: will we introduce a breaking change, or do we keep this inconsistency for the next 10 years or more. And sometimes we go for the breaking change, to improve the usability of the dashboard...
A lot of us develop in our very limited spare time for free. Which means you might overlook things, simply because you don't have the time to analyse everything in full depth and test every scenario. After all we do this just to have a relaxing hobby, after a long day at work.
Joe and his colleagues have already created a lot of automated test flows to minimize the risk of regression. But the test coverage should be much higher. It would help if companies (which earn money by selling the dashboard) would show their appreciation by contributing. For example to improve the suite of test flows, to minimize the risk for regression. For their own benefit...
Yes Dashboard 2.0 is the closest one to our requirements. We developed a beta version software based on DB2. But after a DB2 upgrade several months ago, the "ui-form" stopped working normally. It turns out the input message format was changed. So we decided to wait until DB2 is more mature.
It would be great to keep the messages consistent.
Unfortunately, the major issue we have with UIBUILDER is the frequent breaking changes from version upgrades. We love to see improved performance and more features from version upgrades. Frequent breaking changes cause serious overheads for industrial applications.
The last breaking change before the recent one was 2 years ago! Hardly "frequent".
UIBUILDER is now 10 years old and so breaking changes are pretty rare.
Even in the v7 release, the main change was to use Node.js 18+ in line with Node-RED v4 and so for most people (who will already have upgraded node.js), there wouldn't be any issues.
You should understand that my day-job is as an Enterprise Architect for a major public body and I have over 40 years experience in enterprise IT. So I absolutely understand these things and I absolutely try to minimise breaking changes.
This is also the reason that I'm very conservative about marking things as a "potentially" breaking change. If you look through the change log, you will find that they will rarely impact anyone but they are marked that way to help people like yourselves be sure.
If we release the software to customers, then it means that the customers won't be able to use newer version software, unless they upgrade the dashboard software too. This is fine for small number of customers. For large amount of customers, then it is very costly.
But have they broken anything for you? I'd really like to understand. Most of the changes are certainly not breaking and those that might be won't affect many people at all.
If you are using node.js at all, you do have to accept some level of change since the whole platform is moving at pace, if you need to avoid that, you probably shouldn't be using node.js based tools. Node.js itself is moving at pace and, as mentioned, this was actually the primary reason for moving to a v7 since it isn't impossible that some people might not have updated node.js. But if you'd already moved to Node-RED v4 for example, then you'd already be on the right version of node.js.
So please do let me know if there is anything else in the list of v7 "potentially" breaking changes that actually impacts you.
Also worth noting that v6, while no longer in development is still usable. Even v5 is still usable. Though I don't generally support older versions, if there was a genuine need, it wouldn't be impossible.
To minimize breaking changes, a company should have their own software development under full control.
Here is a delicate balance, providing a commercial product while riding on the free Node-RED and all free time contributors wave is then a risk to be calculated for. Is something that is tempting yes, imagine the full development costs if you would have to have your own organization develop everything yourself. Like larger companies does. I know this, been there, done that.
Ok my personal advice here for ALL companies that earn money by selling free open source software to a large amount of customers. I completely understand that those customers expect quality after have spend money to your company. Who could blame them...
About my feedback about test coverage above, which you have completely ignored. Instead of continuing this discussion (where you demand less breaking changes from developers that you don't pay) I would suggest you start contributing yourself to solve your customers problem.
Joe made some nice documentation about how to write tests. You can find it here. Since you are specialized in Node-RED, I assume your company might have the necessary skills to create (test) flows. So that shouldn't be a blocking issue for you at all. Go for it I would say!
Small sidenote: I don't think you are fully aware of impact of this kind of feedback to the community. I almosted quitted Node-RED last year, because I had completely no idea anymore why I was developing free software in my spare time for people that go for the maximum profit (i.e. selling + zero contributing + be very demanding). This discussion makes it really tempting for me to watch a movie tonight, instead of contributing to the dashboard. Since I am busy migrating all my ui nodes and I became the major (non-paid) contributor for D2, that would mean that your customers have to wait longer for their new dashboard full of new features. Think about that before answering my feedback...
We have been following the change logs of uibuilder for a long time, and see frequent breaking change notes. That's why we did not use uibulder in the first place.
Yes Nodejs updates regularly. But we use the long-term stable functions and it is not a problem.
Completely agree with you. We have extensive tests before each software upgrade, and make sure that everything is consistent. Node-RED is an excellent tool, and we love it as the open source software.
I agree with you that companies should not sell open source software to customers without added value. We provide customized dashboard software to our customers free of charge with industrial knowhow addons. Many customers start to know Node-RED too.
This is simply a suggestion on software development from industrial point of view.
We do go through extensive tests, which is mandatory for industrial applications.
Hopefully it helps on the dashboard usage in the long run.
Please take the advice as a grain of salt.
BTW, not sure who you are talking about selling the software you develop for profit?
So with the exception of a more rapid cadence in 2022, major versions are 1 to 2 years apart. The move from v4 via v5 to v6 did bring a little more change but if you read the docs - as I've repeatedly said - you will see that I am very conservative about changes and that the majority of changes that might be breaking for a few people rarely impact anyone.
The biggest change of all was moving from the old client library to the new one and I kept the old version maintained for years before finally retiring it this year.
I had been collecting the v7 changes for several years while waiting for Node-RED to move to Node.js v18.
If you look at the Node-RED release schedule, you will see that its major version changes are not so very different from mine.
I might also point out that in the same timeframe of UIBUILDER plus a year or so, Dashboard came and went completely due to dependency on a framework that got deprecated. This cannot happen to UIBUILDER. I would have thought that this would be a far larger concern for industrial use.
So I hope you will forgive me for being more than a little exasperated by what you've said.
Hi Julian, thank you very much for the clarification. We will take a look at uibuilder again. uibuilder has excellent features.
For industrial applications, 1-year break change is like "change of heart for newly weds"
