Skip to content

Latest commit

 

History

History
executable file
·
136 lines (83 loc) · 3.54 KB

CONTRIBUTING.md

File metadata and controls

executable file
·
136 lines (83 loc) · 3.54 KB
Raw

Before You Post!

Support

We offer support through our Official Support Channels. Do not use GitHub Issues for support, your issue will be closed.

Contribute

Our Contributing Guide contains useful tips and suggestions for how to contribute to this project, it's worth the read.

Development

Setup

  1. Install Node.js

  2. Fork the project and clone your fork - guide

  3. Install local dependencies

    npm install

  4. Perform any other setup operations

    npm run-script setup

Developing

  1. Compile changes

    npm run-script compile

  2. Run tests

    npm run-script verify

Publishing

Follow these steps in order to implement your changes/improvements into your desired project:

Preparation

  1. Make sure your changes are on their own branch that is branched off from master.

    1. You can do this by: git checkout master; git checkout -b your-new-branch
    2. And push the changes up by: git push origin your-new-branch

  2. Ensure all tests pass:

    npm run-script verify

    If possible, add tests for your change, if you don't know how, mention this in your pull request

  3. Ensure the project is ready for publishing:

    git status
git diff
npm run-script prepare

Pull Request

To send your changes for the project owner to merge in:

  1. Submit your pull request
    1. When submitting, if the original project has a dev or integrate branch, use that as the target branch for your pull request instead of the default master
    2. By submitting a pull request you agree for your changes to have the same license as the original plugin

Publish

To publish your changes as the project owner:

  1. Switch to the master branch:

    git checkout master

  2. Merge in the changes of the feature branch (if applicable)

  3. Increment the version number in the package.json file according to the semantic versioning standard, that is:

    1. x.0.0 MAJOR version when you make incompatible API changes (note: DocPad plugins must use v2 as the major version, as v2 corresponds to the current DocPad v6.x releases)
    2. x.y.0 MINOR version when you add functionality in a backwards-compatible manner
    3. x.y.z PATCH version when you make backwards-compatible bug fixes

  4. Add an entry to the changelog following the format of the previous entries, an example of this is:

    - v6.29.0 April 1, 2013
    - Progress on [issue #474](https://github.com/bevry/docpad/issues/474)
    - DocPad will now set permissions based on the process's ability
        - Thanks to [Avi Deitcher](https://github.com/deitch), [Stephan Lough](https://github.com/stephanlough) for [issue #165](https://github.com/bevry/docpad/issues/165)
    - Updated dependencies

  5. Commit the changes with the commit title set to something like v6.29.0. Bugfix. Improvement. and commit description set to the changelog entry

  6. Ensure the project is ready for publishing:

    git status
git diff
npm run-script prepare

  7. Prepare the release and publish it to npm and git:

    npm run-script release

    A prompt will occur asking you for a git tag annotation, enter the changelog entry that we created earlier, save and exit the prompt.