Skip to content

Latest commit

 

History

History
47 lines (35 loc) · 3.72 KB

CONTRIBUTING.MD

File metadata and controls

47 lines (35 loc) · 3.72 KB
Raw

Contributing

The best way to contribute to the development of this plugin is by participating on the GitHub project:

https://github.com/pantheon-systems/plugin-pipeline-example

Pull requests and issues are welcome!

Workflow

Development and releases are structured around two branches, main and release. The main branch is the main branch for the repository, and is the source and destination for feature branches.

We prefer to squash commits (i.e. avoid merge PRs) from a feature branch into main when merging, and to include the PR # in the commit message. PRs to main should also include any relevent updates to the changelog in readme.txt. For example, if a feature constitutes a minor or major version bump, that version update should be discussed and made as part of approving and merging the feature into main.

main should be stable and usable, though possibly a few commits ahead of the public release on wp.org.

The release branch matches the latest stable release deployed to wp.org.

Testing

Every push lints and tests with PHPCS and PHPUnit. This project uses Pantheon WP Coding Standards.

Release Process

  1. From main, checkout a new branch release_X.Y.Z.
  2. Make a release commit:
    • Drop the -dev from the version number in README.md, readme.txt, and rossums-universal-robots.php.
    • Update the "Latest" heading in the changelog to the new version number with the date
    • Commit these changes with the message Release X.Y.Z
    • Push the release branch up.
  3. Open a Pull Request to merge release_X.Y.Z into release. Your PR should consist of all commits to main since the last release, and one commit to update the version number. The PR name should also be Release X.Y.Z.
  4. After all tests pass and you have received approval from a CODEOWNER, merge the PR into release. "Rebase and merge" is preferred in this case. Never squash to release.
  5. Pull release locally, create a new tag (based on version number from previous steps), and push up. The tag should only be the version number. It should not be prefixed v (i.e. X.Y.Z, not vX.Y.X).
    • git tag X.Y.Z
    • git push --tags
  6. Confirm that the necessary assets are present in the newly created tag, and test on a WP install if desired.
  7. Create a new release using the tag created in the previous steps, naming the release with the new version number, and targeting the tag created in the previous step. Paste the release changelog from the Changelog section of the readme into the body of the release, including the links to the closed issues if applicable.
  8. Wait for the Release rossums-universal-robots plugin to wp.org action to finish deploying to the WordPress.org plugin repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
  9. Check WordPress.org: Ensure that the changes are live on the plugin repository. This may take a few minutes.
  10. Following the release, prepare the next dev version with the following steps:
    • git checkout main
    • git rebase release
    • Update the version number in all locations, incrementing the version by one patch version, and add the -dev flag (e.g. after releasing 1.2.3, the new verison will be 1.2.4-dev)
    • Add a new ### X.Y.X-dev heading to the changelog
    • git add -A .
    • git commit -m "Prepare X.Y.X-dev"
    • git push origin main