|
| 1 | +--- |
| 2 | +layout: blog |
| 3 | +title: Going beyond Node-RED 1.x |
| 4 | +author: nick |
| 5 | +description: With the 1.1.0 release done, it's time to think about what comes next for the project. Find out how we're proposing to approach future releases of Node-RED and what that means for longer term support. |
| 6 | +--- |
| 7 | + |
| 8 | +With the 1.1.0 release done, our attention turns to the next release. But before |
| 9 | +we push ahead with the next item on the backlog, it's a good moment to think about |
| 10 | +the bigger picture |
| 11 | + |
| 12 | +We reached our 1.0 milestone last October. This was a major point for us to reach |
| 13 | +and it took quite a while to get there. And it has taken us 9 months to get to the |
| 14 | +the next release. That delay was not ideal as it has meant many new features |
| 15 | +have been sat around for months, waiting to be released. |
| 16 | + |
| 17 | +This is an unfortunate result of being an open-source project that cannot take |
| 18 | +for granted anyone's involvement. Whilst I am in a fortunate position to be able |
| 19 | +to dedicate a very large part of my day job working on the project, that is not |
| 20 | +the case for many of the other contributors. |
| 21 | + |
| 22 | +Our approach to scheduling releases has been fairly relaxed. We haven't set |
| 23 | +target dates too far in advance and at some point we would decide we have 'enough' |
| 24 | +new content to warrant publishing a new release. |
| 25 | + |
| 26 | +Prior to the 1.0 release, we would also, on occasion, make a change that shouldn't |
| 27 | +be made in a minor-version number release. For example, dropping support for older |
| 28 | +versions of Node. You can just about get away with that when you are a 0.x versioned |
| 29 | +project, but now we are a 1.x versioned project, we need to take more care. |
| 30 | + |
| 31 | +As it stands, we still technically support running on Node.js 8.x - even though |
| 32 | +that version of Node stopped being maintained at the start of this year. And we certainly |
| 33 | +have an eye on the fact that Node 10.x drops out of maintenance at the end of April |
| 34 | +next year. |
| 35 | + |
| 36 | +Whilst we certainly wouldn't recommend it, we understand some users are stuck on |
| 37 | +older versions, and we don't want to needlessly break them if we can avoid it. |
| 38 | + |
| 39 | +But nor can we continually hold ourselves back from being able to make use of new |
| 40 | +Node.js features in the core runtime. |
| 41 | + |
| 42 | +We also recognise that for the companies who have adopted Node-RED into their own |
| 43 | +commercial solutions, they need a degree of confidence in how long any particular |
| 44 | +version of Node-RED will be supported. |
| 45 | + |
| 46 | +So with all of that in mind, here is the current *proposal* for how we manage |
| 47 | +releases in the future. |
| 48 | + |
| 49 | + |
| 50 | + |
| 51 | +At the bottom, the chart shows the [published dates](https://nodejs.org/en/about/releases/) |
| 52 | +for the current Node.js releases. If you are using Node.js in any sort of production |
| 53 | +environment, you need to be aware of these dates. |
| 54 | + |
| 55 | +The top shows the proposed release schedule for Node-RED. |
| 56 | + |
| 57 | +In summary, we aim to do a minor version release (for example, 1.1 → 1.2) |
| 58 | +every three months. Maintenance releases (for example 1.1.0 → 1.1.1) will continue |
| 59 | +to happen as and when they are needed. |
| 60 | + |
| 61 | +At the end of April 2021, when Node 10.x reaches its end-of-life, we will publish |
| 62 | +Node-RED 2.x that will *drop* support for both Node 8.x and Node 10.x. |
| 63 | + |
| 64 | +The 1.x stream will then enter maintenance mode. It will only receive bug fixes |
| 65 | +and security updates. New features could get back-ported from 2.x if there was |
| 66 | +a very good reason to do so as well as people available to do the work. |
| 67 | + |
| 68 | +The 2.x stream will continue in active development with a minor release every |
| 69 | +three months or so until April 2022 when Node 12.x reaches its end-of-life. We |
| 70 | +then publish Node-RED 3.x and the cycle continues. The 1.x stream will reach its |
| 71 | +end-of-life soon after the 3.x release. The exact timing of that will be something |
| 72 | +we will need to discuss further. |
| 73 | + |
| 74 | +This proposal means: |
| 75 | + |
| 76 | + - We have a regular cycle of releases - getting new features into the hands of users. |
| 77 | + - We have a schedule to help us prioritise and plan backlog items. |
| 78 | + - We can provide longer-term stable releases with a well-known end of life. |
| 79 | + - We have a plan that enables us to make potentially breaking changes once a year. |
| 80 | + |
| 81 | +It is important to remember this plan is not risk-free. It assumes that the project |
| 82 | +has enough contributors to help deliver it. This becomes particularly important when |
| 83 | +we have multiple streams to maintain. |
| 84 | + |
| 85 | +We're hopeful that having a published schedule of releases will help encourage |
| 86 | +people to contribute, whether in code, documentation, testing or just general feedback. |
| 87 | + |
| 88 | +We will see how it goes over the next few months - we have until April before we |
| 89 | +will have multiple active streams. If something isn't working and we have to |
| 90 | +rethink this plan, then we will. |
| 91 | + |
| 92 | +I've added a [summary of this plan to the About section](/about/releases/) of the site for future |
| 93 | +reference. |
| 94 | + |
| 95 | + |
| 96 | + |
| 97 | + |
0 commit comments