Skip to content

Latest commit

 

History

History
106 lines (78 loc) · 3.24 KB

CONTRIBUTING.md

File metadata and controls

106 lines (78 loc) · 3.24 KB

Contributing to the source

Contributions are welcomed via pull requests. Contact the WEST developers before starting work to ensure it meshes well with the planned development direction and standards set for the project.

Version control

All changes in a pull request should be closely related. Multiple change sets that are loosely coupled should be proposed in separate pull requests. Use a consistent style for writing code.

Features

New features should be applicable to a variety of use-cases. The WEST developers can assist you in designing flexible interfaces.

Testing

Add tests for all new functionality.

Release

We use semantic versioning, i.e. version labels have the form v<major>.<minor>.<patch>

  • Patch release: v0.0.0 to v0.0.1, only bug fixes
  • Minor release: v0.0.0 to v0.1.0, bug fixes and new features that maintain backwards compatibility
  • Major release: v0.0.0 to v1.0.0, bug fixes and new features that break backwards compatibility

Contributing to the documentation

Comment complex sections of code so that other developers can understand them. Add demonstrations of new functionality, e.g. using Jupyter notebooks.

Developer's workflow

  1. Clone the repository to your local machine:
  $ git clone <https-or-ssh-git-repo>
  1. Use the following to see all the available branches and which branch you are on:
  $ git branch -a
  1. Create a branch for the feature you are going to work on. Internal users should branch from the develop branch.
  $ git checkout -b <myfeature>
  1. Make changes to the repository:
  $ touch <file>
  1. Check which files have been changed in your local directory by:
  $ git status
  1. Commit your changes and push to the remote repository:
  $ git add <file>
  $ git commit -m "explain your modification"
  $ git push origin <myfeature>
  1. (Optional) Check commit history by:
  $ git log

  1. Then create a pull request on github.com that hosts the remote repository.

  2. You can do one of the following after the pull request has been approved or closed:

    • Delete the branch myfeature
    • Keep the original branch and keep working on it

Often-encountered scenarios

  1. When you want to add another feature, create a new branch for the new feature, e.g. another_feature, branching from the latest develop branch.

First switch to the develop branch:

  $ git checkout develop

Then update the local develop branch to include changes to the remote:

  $ git pull origin develop

Then create your new branch:

  $ git branch -b <another_feature>

Then repeat #4-#9 above.

  1. Suppose you are working on your feature branch and other people have changed the develop branch in the remote repository after you created your myfeature branch, you need to merge the develop branch into your myfeature branch before submitting a pull request.

To merge the develop branch into your myfeature branch, you need to checkout your myfeature branch:

  $ git checkout <myfeature>

Then do the following to merge the develop branch into your branch:

  $ git pull origin develop

Then do #6-#9 above.