2 Contribution Process

Nick O'Leary edited this page 2017-02-28 10:47:31 +00:00

Table of Contents

• Git Workflow
• Raising a pull-request

Git Workflow

• master - this branch contains the latest shipped release of node-red, plus any additional bug fixes that have been made since. At any time, this branch could get shipped as the next maintenance release. At the time of writing, this contains 0.16.2 and a few fixes that will be released as 0.16.3 at some point.
• Development branch (eg 0.17) - development work on the next milestone release occurs in a branch named after the expected release version number. This is where new features are developed. At the time of writing, this is the 0.17 release.
• Larger features get developed in their own branches and merged to the current development branch as and when the feature is sufficiently stable for wider consumption.

Raising a pull-request

Code contributions arrive as pull requests. They should target the appropriate branch - bug fixes on released code to master, new features to the current development branch.

There are a lot of good guides to working with pull requests and we won't try to recreate them here. But the basic process is:

1. Fork the repository you want to make a change on
2. Create a branch on your fork for the changes
3. Run the tests!
4. Create a pull request to the upstream repository. Make sure you target the appropriate branch of the upstream repository. If you want, you can choose to allow us to commit changes to your branch - that may be useful if there are some changes needed on top of your code and we're in a position to help make them.

Once the PR is raised, we'll review the changes and provide feedback. If all looks good, we'll get it merged. Otherwise we may request some changes or decide the PR isn't suitable to merge. Either way, we'll discuss it via the PR.

• Design Notes
• Tech Interchange Meetings