RFC: prefixing all nodes with uhppoted- to avoid naming conflicts

[uhppoted]

On digging a bit further into Config node name conflict #11 it seems that the following nodes have conflicts with other packages:

• config
• get-status
• get-devices
• get-device
• listen

Since the v1.0.0 release is unfortunately going to have to be a breaking change (there doesn't seem to be any other way to fix Config node name conflict that isn't more complicated and fragile) , I am proposing to prefix all the node names with uhppoted- to avoid other potential conflicts.

Any comments? Suggestions? Better ideas?

@dpslwk, @dastrix80, @taufpate, @TestUser0000000001, @neyStyle, @savage7, @jhcloos, @twystd - can you please advise the impact (if any) on your systems?

[dpslwk]

Makes sense to do it all in one go and to be more eco-system friendly.

Looks like it may just be the registerType (and its use) that needs to be prefixed
and you can add paletteLabel to the html to keep the prefix out of the frontend display label

[uhppoted]

Ah! Thanks! Was just thinking the names were going to become really unwieldy.

Am considering doing an interim release with a duplicate set of nodes (e.g. get-device and uhppoted-get-device) so that existing flows can be migrated more easily. Will experiment a bit and see.

[taufpate]

No impact for me :-)

[uhppoted]

Thought probably not :-) :-) .. thanks for letting me know!

[uhppoted]

Quick update: the migration plan to address this issue looks like this:

1. Release v0.9.0 (probably early next week) with a duplicate set of nodes that have been renamed with a uhppoted- prefix. The existing nodes will be retained but will have a deprecation warning (red colour, -deprecated label and DEPRECATED warning in the info section). Existing flows will continue to work but anybody who wants to can start migrating their flows to the new nodes.

2. If there are no major issues with v0.9.0, make v1.0.0 available as an early access release (probably a week later) in a separate branch for anybody who wishes to migrate early. v1.0.0 will be the v0.9.0 release but with all the old nodes removed.

3. Publish v1.0.0. to npm.js and nodered.org about a week later (assuming of course no major issues turn up in testing)

4. And a week after that release v1.0.1 which will require NodeRED v3.0 in order to update dependencies with security patches.

Apologies for any inconvenience, but this is the only way I could think of to give any systems out there sufficient warning and also a migration path that will allow them to update incrementally if they so choose. And also to migrate anybody stuck on NodeRED v2.2 for whatever reason.

[uhppoted]

Quick update:

1. v0.9.0 has been published and is available on NodeRed and npm.js - unfortunately with a README that seems to break NodeRED's page formatting :-(.
2. A provisional v1.0.0 release is available in branch v1.0.0, with a version number of v0.9.9 to facilitate upgrading to v1.0.0 when it's published.

[uhppoted]

Quick update:

1. v1.0.0 has been published and is available on NodeRed and npm.js.
2. _v1.1.0 with NodeRED v3.0.2, the latest security patches and some minor packaging fixes for the scorecard will (hopefully) be published next week and that will be a wrap :-)

[uhppoted]

And .. final update:

1. v1.1.0 which requires NodeRED v3.02 for some long outstanding security patches is on NodeRED