Skip to content

Latest commit

 

History

History
118 lines (74 loc) · 3.26 KB

Contributing.md

File metadata and controls

118 lines (74 loc) · 3.26 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. Setup the project for development

    npm run our:setup

Developing

  1. Compile changes

    npm run our:compile

  2. Run tests

    npm test

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 test

    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:

    npm run our:release: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 2013 April 1

-   Progress on [issue #474](https://github.com/docpad/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/docpad/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:

    npm run our:release:prepare

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

    npm run our:release