Skip to content

Latest commit

 

History

History
134 lines (105 loc) · 5.17 KB

CONTRIBUTING.adoc

File metadata and controls

134 lines (105 loc) · 5.17 KB
Raw

Contributing to vagrant-service-manager

The following is a set of guidelines for contributing to the vagrant-service-manager plugin. These are guidelines, please use your best judgment and feel free to propose changes to this document.

Table of Contents

Submitting issues

You can submit issues with respect to the vagrant-service-manager 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. The vagrant-service-manager plugin works closely with the Atomic Developer Bundle and the adb-utils RPM. You may wish to review the issues in both these repositories as well.

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 vagrant-service-manager 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 (see submitting issues). Assuming for example you will be working from the master branch and working on the GitHub issue 123 : git checkout -b fix-123 master

Code

Do your work! Refer to the development section in the README to get started.

Commit

  • Make commits of logical units.

  • Be sure to use the GitHub issue key in the commit message, eg Fix #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.

  • All changes need at least 2 ACKs from maintainers before they will be merged. If the author of the PR is a maintainer, their submission is considered to be the first ACK. Therefore, pull requests from maintainers only need one additional ACK. By "2 ACKs" we mean that two maintainers must acknowledge that the change is a good one.

Merging pull requests

A project maintainer will merge the pull request. He should avoid using the GitHub UI for the merge and prefer merges over the the command line to avoid merge commits and to keep a linear commit history. Here is an example work-flow 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

# If required, update CHANGELOG.md in the unreleased section. Commit!

# 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. You can also verify against CI

  • 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: vagrant-service-manager version=<version>

  • Push commit to upstream

  • Release the gem: bundle exec rake release

  • Create a Github release and paste change log for release

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

  • Commit with message: vagrant-service-manager setting dev version <version>.dev

  • Push upstream

Maintainers