I've been asked this a couple times, so thought I'd share this post just to keep everyone up to date.
The goal was to get Node-RED 1.0 released in June. Whilst we did successfully start publishing betas in June (no small achievement in itself), you will have noticed we haven't got to the final 1.0 release yet.
Simply put, it isn't finished yet. One of the big challenges of scheduling in an open source project is that when you don't have a development team dedicated to the task, you are reliant on the contributions of the community to help get things delivered.
The main remaining development work has become queued up on me, and as I've waded through it, some unexpected design questions have been thrown up that have then lead to further work.
Also, it isn't all just about the code. For a release like 1.0, it is an opportunity for us to make a splash and have the project benefit from the publicity it will generate. There's a lot fo work to be done to make the most of that. For example, you'll have noticed the refresh of all the documentation I did a couple weeks ago - that was a few solid days I spent on documentation rather than delivering code.
As we are now entering holiday season, we decided there's no point trying to get a major release done whilst everyone is on the beach - particular when we want to be on the beach as well.
So the revised plan is to get the next beta out at the end of July, another beta mid/late August and then the final release in September.
Let us know if you have any questions.
And with that, I head off to a beach for a week without my laptop.
All reasonable points, there is no need to rush with this release. It's done when it's done. Thanks to you and all contributors, you are doing a great job with this platform!
I'm all for continuous improvement, but once you get to a certain critical mass of users and functionality "if it ain't broke, don't fix it!" becomes important.
If 1.0 breaks things that have been working fine running 24/7/365 for the past year I won't be a happy camper! New features may be crucial in the future, but only if adding them doesn't break what is working now.
I've had minor breakage with updates, one in a contrib node that I relied on, and the issue ultimately was below node-red in the nodejs library used in the contrib node. The other was somewhat mysterious where the updated MQTT "auto" setting turned my mqtt buffers into strings. I'll be on the lookout for it with other system updates and fresh installs as consensus from another thread is that it "shouldn't have happened". But it did, and was trivial to fix once I discovered the problem -- switch "auto" property to buffer or string as required, the old version didn't have this option and somehow always seemed to get it right.
I guess my real point is node-red has reached a maturity level where rushing an update could do far more harm than any possible good form the "new and improved" publicity.
That is the main point of having beta releases. You could install that and see if it gives any problems for you, if so then they can be fixed before release.
The obvious answer is "if it ain't broke, don't upgrade it"... there is responsibility at both ends of this bargain. I still have a system running Node-RED 0.9.0 on my desk as it just does what I need it to.
Also from some places we have feedback that Node-RED is not ready for production as it's not 1.0... as we have plenty of evidence that is not the case from users both large and small... we also want to "move" to 1.0 as seamlessly as possible and silence that objection.
We currently have no intention of breaking anything when we go to 1.0 - however as it is a semantic major version bump there we are taking the opportunity to change a few things, that will hopefully better position us for other future changes that we would like to do.
One of these is making all message passing asynchronous between nodes. For the majority of users this will make no difference at all, but for a very small number it may, as it will affect the processing order of downstream nodes. Rather than executing a branch synchronously to completion and then handling the next branch, each branch will be called right after the other. In the pic below - currently if you hang debug off all downstream nodes you would see D report first then C then B then E - which feels illogical and doesn't match most peoples mental model. Making it async should mean you get B,C,D then E.
This will be in the next beta - hence why we didn't want to rush it out just before vacation. There will be a setting to revert this if you really need the synchronous behaviour.
Other changes are mainly cosmetic (re-ordering palette menu), or additional functionality (better subflow options and ui).
Of course due to the power of npm - you can continue to install any previous version you wish by specifying the version fully when installing.
Will this have the side effect of meaning that a function node will run to completion before any of the messages it sends are actioned? Currently if a node sends a message using node.send (in its main path through, I am not talking about asynchronous operations inside the node using setTimeout for example) and that message gets looped back via another function node for example back to the first nodes input then the first node will start actioning the new message before it runs the code after the node.send.
Sorry but I must disagree strongly with this statement. It may have reached maturity for the things that you want to do with it just now - but that isn't true for other people. There are a great many things that need improving in Node-RED - that isn't a criticism, simply a statement of reality. It has a relatively small set of core developers and so things take time to move forward.
At the same time, I would agree that Node-RED is remarkably stable given its nature and where it has come from. It always amazes me that, as open source JavaScript Node.js, it is far more stable than many commercial systems I have to put up with.
I've had some massive breakages which is why I learned long ago to take a full copy of my working folder before doing anything but a minor updated. This is one of the reasons I ended up with the alternate install that I've just released - so that everything could be kept together making it really easy to make an exact duplicate and just as easy to roll back to the known working version.
A Dave says, this is business as usual for any production system anyway. You always plan for failure.
Oh wow! That is great, I still get confused with output order even now. I'm liking that already Though it means that I need to think about what it means to my live system.
Yes, I did one of those not long back - what a c**k up that was! You'd have thought I would have learned after all these years - but apparently not.
No, absolutely not!
When developing, nobody can predict and foresee all needed / wanted functionality for years.
So it is perfectly fine and normal to make corrections (hey, it's only v 1.0!) instead of living the rest of your life with a big quirks (just take a look at Windows)
I would gratefully accept every change for complete dynamic properties, gui in subflows, multiuser, etc
Thanks but being on vacation we aren’t looking at (or thinking about) flows right now. As I said most users probably won’t be affected. If you do something torturous then yes you could find a path that behaves differently. Will try it when we release the next beta.
I don't want it to behave the way it does now, I am hoping it will operate as one would expect, completing the execution before the sent messages get serviced. The existing unnexpected operation has caused bugs in more that one node, including at least one core node if I remember correctly.
Absolutely. My upgrade issues were from installing my code on new freshly installed systems. As I said problems were minor. I try to track current versions on stuff I developing, but once its "finished" its all pain and no gain for "updates. Like it or not, that is the reality of why there are still plenty of XP systems still out there.
The complication comes if you need to install old versions on new systems. Maybe the getting started docs should mention how to install install older versions on new systems if compatibility issues makes it necessary.
I'm still running Jessie (Debian 8).on my Beaglebone Black. It only reboots after power failures that last longer than the UPS can keep it up -- its current uptime is like 514 days. This system is so specific I doubt it'd ever be installed anywhere else, but I keep a "cloned" sd card ready in case a replacement system is ever needed. I also have a spare Beaglebone sitting on a shelf in case their availability becomes an issue down the road.
Eeek! I really hope that you aren't suggesting this as a viable approach to production systems! If any of my staff even thought such a thing, they would be out of a job within 5 seconds.
For production systems, we have very well defined patching and update schedules and we require our vendors (via contract schedules) to do the same.
No system is allowed to be more than n-1 versions out of date (that will usually be referring to Long Term Support versions rather than minor versions) with security patches required much more rapidly.
Indeed there are. Again, not something that will happen with services I am responsible for. Even for embedded systems (that is the majority of XP use left within the UK NHS for example), we require vendors to contractually agree that all systems must be upgradable and follow the same upgrade cycle as everything else.
That is where Docker, et. al. comes in.
Me too on my live Pi. It still gets critical updates. Though I will have to update when Debian 11 eventually gets released and Rasbian follow suit. Since after that, Jessie will become obsolete.
However, my Pi systems (and my NAS which is also reaching end of support) are home-based and kept away from the Internet and locked down. So the risks are minimal. The Pi's aren't really an issue as they are easily upgraded. The NAS is rather harder since it is expensive.
This is different to running production, commercial systems.
It does really depend on what the 'system' is doing. If it is, for example, a Pi with no access to the internet, doing a defined job satisfactorily, then there is no need to update anything.
