Skip to content

Latest commit

 

History

History
112 lines (84 loc) · 3.75 KB

CONTRIBUTING.adoc

File metadata and controls

112 lines (84 loc) · 3.75 KB
Raw

Contributing to Landrush

The following is a set of guidelines for contributing to the Landrush plugin.

Table of Contents

Submitting issues

You can submit issues with respect to the Landrush plugin here. Make sure you include all the relevant details pertaining the issue.

Before submitting a new issue, it is suggested to check the existing issues in order to avoid duplication.

Submitting pull requests

Get Started

If you are just getting started with Git and GitHub there are a few prerequisite steps.

  • Make sure you have a GitHub account.

  • Fork the Landrush repository. As discussed in the linked page, this also includes:

    • Setting up your local git install.

    • Cloning your fork.

Create a topic branch

Create a topic branch on which you will work. The convention is to name the branch using the issue key you are working on. If there is not already an issue covering the work you want to do, create one. Assuming for example you will be working from the master branch and working on the GitHub issue 123 : git checkout -b issue-123 master

Code

Do your work! Refer to the development guide to get started.

Commit

  • Make commits of logical units.

  • Be sure to use the GitHub issue key in the commit message, eg Issue #123 …​.

  • Make sure your code conforms to the coding style

  • Make sure you have added the necessary tests for your changes.

  • Make sure you have added appropriate documentation updates.

  • Run all the tests to assure nothing else was accidentally broken.

Submit

  • Push your changes to the topic branch in your fork of the repository.

  • Initiate a pull request.

Merging pull requests

A project maintainer will merge the pull request. Here is an example work-flow of a merge assuming issue 123 from above:

# Create a local branch for the pull request
$ git checkout -b fix-123 master

# Pull the changes
$ git pull <remote of the pull request> fix-123

# If necessary rebase changes on master to ensure we have a fast forward.
$ git rebase -i master

# Merge changes into master
$ git checkout master
$ git merge fix-123

# Push to origin
$ git push origin master

Releasing

  • Make sure the HEAD of development builds and passes all tests: bundle exec rake clean rubocop test features install.

  • Review milestone for the current release

    • Make sure all issues are resolved

    • Move unresolved issues into an upcoming release

    • Close milestone

  • Update the CHANGELOG

  • Update version.rb with the correct release version. Consider Semantic Versioning guidelines when deciding on the release version

  • Commit CHANGELOG and version.rb using commit message of the form: cut v<version>

  • Push commit to upstream

  • Release the gem: bundle exec rake release

  • Update version.rb with the next anticipated release version, eg 1.4.0.dev

  • Commit with message: setting dev version <version>.dev

  • Push upstream

Maintainers

  • Brian Exelbierd (@bexelbie)

  • Eric Sorenson (@ahpook)

  • Florian Holzhauer (@fh)

  • Hardy Ferentschik (@hferentschik)

  • Josef Strzibny (@strzibny)

  • Paul Hinze (@phinze)

  • Reto Kaiser (@njam)