Corrects Node-RED mentions (#385)

* Correct mentions of Node-RED

* Additional cases

Author: dimitrieh

_posts/2015-02-08-version-0-10-1-released.md

@@ -36,7 +36,7 @@ One footnote regarding subflows, as they are handled slightly differently. If an
 
 #### Securing the Editor
 
-In previous releases, the editor could be secured using HTTP Basic Authentication by hardcoding a username/password in the settings file. Whilst that worked for simple local installations of node-red, it was never really a good solution.
+In previous releases, the editor could be secured using HTTP Basic Authentication by hardcoding a username/password in the settings file. Whilst that worked for simple local installations of Node-RED, it was never really a good solution.
 
 This release brings a better framework for securing the editor.
 

_posts/2015-02-25-changing-where-node-red-stores-data.md

@@ -5,28 +5,28 @@ author: nick
 ---
 
 One of the things we've been thinking about recently is our upgrade process.
-How does a user go from version A of node-red to version B with as little effort as possible.
+How does a user go from version A of Node-RED to version B with as little effort as possible.
 
-By default, we write your data to the directory that node-red has been installed. This means you cannot just replace that directory with the newest version of node-red. You first have to backup your data first. Whilst this is obviously always a prudent thing to do, what exactly constitutes 'your data' is a longish list of files/directories that is prone to mistakes that leads to something getting lost - especially for users who are not so used to copying files around etc.
+By default, we write your data to the directory that Node-RED has been installed. This means you cannot just replace that directory with the newest version of Node-RED. You first have to backup your data first. Whilst this is obviously always a prudent thing to do, what exactly constitutes 'your data' is a longish list of files/directories that is prone to mistakes that leads to something getting lost - especially for users who are not so used to copying files around etc.
 
 It also meant we often told users to run from a git clone of the repository - as the upgrade path there is simply running `git pull` and `npm update`. But this left users running the latest development code, not the latest stable release - far from ideal for reasons I'll discuss later.
 
-We have had the `userDir` setting for a while now that allows you to point to a directory that all of your data should be put - that helps to keep it separate from the node-red install. One of our rules around things 'Just Working' is that we should have the right default behaviour. As soon as we require a user to edit settings.js in order to ensure their data is somewhere sensible, we're failed.
+We have had the `userDir` setting for a while now that allows you to point to a directory that all of your data should be put - that helps to keep it separate from the Node-RED install. One of our rules around things 'Just Working' is that we should have the right default behaviour. As soon as we require a user to edit settings.js in order to ensure their data is somewhere sensible, we're failed.
 
 ### A new default
 
-The upcoming 0.10.4 release of node-red will include a change to the default behaviour of node-red: user data will be written to the directory `$HOME/.node-red/`. This ensures your data is kept separate from the node-red install, meaning an upgrade is much easier to do - you just upgrade node-red.
+The upcoming 0.10.4 release of Node-RED will include a change to the default behaviour of Node-RED: user data will be written to the directory `$HOME/.node-red/`. This ensures your data is kept separate from the Node-RED install, meaning an upgrade is much easier to do - you just upgrade Node-RED.
 
 
-To ensure complete backwards compatibility, the following steps are taken by node-red when it decides where to store data:
+To ensure complete backwards compatibility, the following steps are taken by Node-RED when it decides where to store data:
 
  1. if `userDir` is explicitly specified at start-up, either via `settings.js` (as before), or via a new command-line argument:  `node red.js --userDir /var/node-red/data`
 
   This means users who already set `userDir` are unaffected, and it is even easier to explicitly point at a specific directory if you want to switch between configurations quickly.
 
- 2. if we detect the presence of user data in the node-red install directory (specifically, the presence of the `.config.json` file), we will continue to use the node-red install directory to store the data.
+ 2. if we detect the presence of user data in the Node-RED install directory (specifically, the presence of the `.config.json` file), we will continue to use the Node-RED install directory to store the data.
 
-  This will mean existing node-red installs will continue to run as before. We will not move existing data to `$HOME/.node-red`
+  This will mean existing Node-RED installs will continue to run as before. We will not move existing data to `$HOME/.node-red`
 
  3. if none of the above applies, we will use `$HOME/.node-red`. In other words, brand new installs will do this.
 
@@ -36,9 +36,9 @@ The documentation on [how to upgrade](http://nodered.org/docs/getting-started/up
 ## Installing Node-RED
 
 
-This change also brings a change to how we recommend node-red is installed. Rather than downloading zip file, we will recommend the use of npm to install node-red.
+This change also brings a change to how we recommend Node-RED is installed. Rather than downloading zip file, we will recommend the use of npm to install Node-RED.
 
-The following command will do a global install of node-red:
+The following command will do a global install of Node-RED:
 
     sudo npm install -g node-red
 
@@ -56,9 +56,9 @@ If you choose to install it locally, rather than globally, you can still upgrade
 
 Some users chose to clone the git repository and run from there. This has the advantage of getting all of the very latest changes, but it has always been at the risk of picking up still-under-developement code.
 
-In the very near future, we will be adding a build step into the development process that will sit between the code in git and what constitutes a runnable instance of node-red.
+In the very near future, we will be adding a build step into the development process that will sit between the code in git and what constitutes a runnable instance of Node-RED.
 
-You will _not_ be able to run node-red straight from a git clone without first running a build. This will require the development dependencies to be installed - not just the production ones.
+You will _not_ be able to run Node-RED straight from a git clone without first running a build. This will require the development dependencies to be installed - not just the production ones.
 
 We'll share more details of this just before it goes into the repository. But by way of advanced warning, if you are running from git just to get the very latest code, be prepared.
 

_posts/2015-04-01-version-0-10-6-released.md

@@ -18,7 +18,7 @@ You may have spotted this release is `0.10.6`. You may be wondering what happene
 
 Previously, the very last commit I do before cutting a new release is to bump the version number in `package.json`. At that point, anyone who installed the release from npm would get that version. We would then continue development in git. If someone wanted to try out the latest code from git by cloning the repository, it would still have the same version number in its `package.json` as the previous release.
 
-This has caused some confusion for users when reporting issues as well as some technical headaches for automated builds that pull in node-red as a dependency.
+This has caused some confusion for users when reporting issues as well as some technical headaches for automated builds that pull in Node-RED as a dependency.
 
 By immediately bumping the version in git following a release (to make it odd), and also bumping it immediately before the next release (to make it even) helps to identify the different levels.
 

_posts/2015-06-16-version-0-10-8-released.md

@@ -18,24 +18,24 @@ Remember, at this time, we **do not** support Node.js v0.12 or io.js.
 
 ### Nodes (re)moved
 
-One of the main changes we've made is to move some of our core nodes out to their own individual packages. This enables us to ship fixes for these nodes independently of the main release. Some of these nodes have been added as dependencies of the node-red package so they will get automatically included when `npm install` is run. Some of the nodes are no longer included and have to be manually added back in.
+One of the main changes we've made is to move some of our core nodes out to their own individual packages. This enables us to ship fixes for these nodes independently of the main release. Some of these nodes have been added as dependencies of the Node-RED package so they will get automatically included when `npm install` is run. Some of the nodes are no longer included and have to be manually added back in.
 
-The following nodes have moved to their own npm package and have been added as dependencies of the node-red package so will still get included:
+The following nodes have moved to their own npm package and have been added as dependencies of the Node-RED package so will still get included:
 
  - Twitter, now provided by `node-red-node-twitter`
  - Feedparse, now provided by `node-red-node-feedparser`
  - Email, now provided by `node-red-node-email`
  - Serialport, now provided by `node-red-node-serialport`
 
 
-The following nodes have moved to their own npm package but have **not** been added as dependencies of the node-red package. This means, if you are using any of these nodes, you'll need to *manually install their new npm package to continue using them.*
+The following nodes have moved to their own npm package but have **not** been added as dependencies of the Node-RED package. This means, if you are using any of these nodes, you'll need to *manually install their new npm package to continue using them.*
 
  - IRC: `node-red-node-irc`
  - Arduino: `node-red-node-arduino`
  - Redis: `node-red-node-redis`
  - Mongo: `node-red-node-mongodb`
 
-Because we know not everyone reads these release notes, if node-red detects you are using any of these moved nodes, it will very clearly point you at the appropriate package to install.
+Because we know not everyone reads these release notes, if Node-RED detects you are using any of these moved nodes, it will very clearly point you at the appropriate package to install.
 
 
 ### Other changes

_posts/2015-11-06-version-0-12-0-released.md

@@ -12,7 +12,7 @@ If upgrading, please read the [upgrade instructions](http://nodered.org/docs/get
 
 ### Updated to Express 4.x
 
-Express is the web framework we use to serve up the editor, admin api and the HTTP nodes. We've been using Express 3.x since the start, but that version is no longer maintained so we've had to move up to the latest stable version 4.x. A major version number bump like that indicates some breaking api changes in the library which, on the whole, we can hide from the Node-RED user. But if you embed node-red into your own application, and provide your own instance of Express, there may be hiccups if the versions don't match.
+Express is the web framework we use to serve up the editor, admin api and the HTTP nodes. We've been using Express 3.x since the start, but that version is no longer maintained so we've had to move up to the latest stable version 4.x. A major version number bump like that indicates some breaking api changes in the library which, on the whole, we can hide from the Node-RED user. But if you embed Node-RED into your own application, and provide your own instance of Express, there may be hiccups if the versions don't match.
 
 I've said before on the mailing list that one of my regrets with early choices made in Node-RED was that we exposed the raw Express request and response objects on the message sent by the `HTTP In` node. We want to get to a point where we can reliably encode and decode message objects to a JSON format - that isn't something we can do today with these objects attached to the message. So with this release, we are deprecating the use of any of the functions these objects provide. They will still work in this release, but you will get warning messages in the log. Most functions have alternatives that can be used - if you're not sure, jump on the [mailing list](https://groups.google.com/forum/#!forum/node-red) and ask.
 

_posts/2016-10-11-version-0-15-released.md

@@ -153,7 +153,7 @@ will be the last one to support node 0.10 *and* 0.12.
 This means, for now, the Raspberry Pi preinstall will be fixed at 0.15.
 To make life easier, we already include a script on the preinstall image called
 `update-nodejs-and-nodered` that updates node.js to the latest LTS version using the
-NodeSource repositories and then reinstalls node-red on top. See [the documentation](http://nodered.org/docs/hardware/raspberrypi.html#upgrading-nodejs) for more information - including instructions for doing that upgrade manually if you so
+NodeSource repositories and then reinstalls Node-RED on top. See [the documentation](http://nodered.org/docs/hardware/raspberrypi.html#upgrading-nodejs) for more information - including instructions for doing that upgrade manually if you so
 choose.
 
 #### Serial node

_posts/2020-10-13-future-plans.md

@@ -277,7 +277,7 @@ users - but will play an important role when looking at running Node-RED at scal
 One very common question we get is around multi-tenancy - having multiple users
 share a single Node-RED instance without getting in each other’s way.
 
-Our long-stated recommendation has been that the node-red runtime is not suited
+Our long-stated recommendation has been that the Node-RED runtime is not suited
 for multi-tenancy. This is down to a number of reasons. Node.js is a single-threaded
 runtime - there is only one event loop that must be shared between all of the
 flows in the runtime. If one user creates a flow that uses a lot of resources,

_posts/2020-10-15-version-1-2-released.md

@@ -101,7 +101,7 @@ downgrade, but it will no longer be updated.
 This is part of the pluggable message routing work that has been in our roadmap
 for a long time now. It is less relevant to end users at this point in time,
 but will underpin a lot of exciting features in the future, such as a proper
-flow debugger, distributed node-red runtimes and integrated flow testing.
+flow debugger, distributed Node-RED runtimes and integrated flow testing.
 
 [More details](https://github.com/node-red/node-red/pull/2665)
 

_posts/2022-07-14-version-3-0-released.md

@@ -271,6 +271,6 @@ very much on the feedback from the community.
 If you're interested in contributing to Node-RED, now is a good time to come over
 and chat with us in either the [forum](https://discourse.nodered.org) or [slack](https://nodered.org/slack).
 
-Node-Red 2.x is now in maintenance mode - we won't be added any new features to it,
+Node-RED 2.x is now in maintenance mode - we won't be added any new features to it,
 but we will do maintenance releases with fixes as needed. In fact, we'll have a
 long overdue 2.2.3 release in the next couple of weeks.

_posts/2024-06-20-version-4-0-released.md

@@ -165,7 +165,7 @@ Given we didn't hear a lot of complaints in the 3.1 release about this, either t
  - The following configuration options have been added to the default settings file:
    - `httpAdminCookieOptions` can be used to customise the options set on cookies as part of the authentication system.
    - `httpStaticCors` can be used to set custom cross-origin resource sharing rules for the content served up via the `httpStatic` option 
- - `node-red --version` now reports the node-red, node.js and os information without starting Node-RED.
+ - `node-red --version` now reports the Node-RED, node.js and os information without starting Node-RED.
 
 
 ## Node Updates