This repository has been archived by the owner on Jul 26, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'release/1.6.0' into stable
- Loading branch information
Showing
24 changed files
with
3,453 additions
and
1,749 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,43 +1,51 @@ | ||
--- | ||
name: Bug report | ||
about: Create a report to help us improve | ||
about: Report a bug with the HRS Blocks plugin. | ||
--- | ||
|
||
**Describe the bug** | ||
|
||
A clear and concise description of what the bug is. | ||
|
||
**To reproduce** | ||
|
||
Steps to reproduce the behavior: | ||
|
||
1. Go to... | ||
2. Click on... | ||
3. Scroll down to... | ||
4. See error | ||
|
||
**Expected behavior** | ||
|
||
A clear and concise description of what you expected to happen. | ||
|
||
**Screenshots** | ||
|
||
If applicable, add screenshots to help explain your problem. | ||
|
||
**The system showing the bug (please complete the following information):** | ||
|
||
- OS: [e.g. iOS, Ubuntu, Windows] | ||
- OS Version: [e.g. 12.2, 16.04, 10] | ||
- Browser [e.g. chrome, safari, firefox] | ||
- Version [e.g. 22] | ||
|
||
**Smartphone (please complete the following information):** | ||
|
||
- Device: [e.g. iPhone6] | ||
- OS: [e.g. iOS8.1] | ||
- Browser [e.g. stock browser, safari] | ||
- Version [e.g. 22] | ||
|
||
**Additional context** | ||
|
||
- Please add the version of WordPress you are using. | ||
## Description | ||
<!-- Please write a brief description of the bug. --> | ||
|
||
## Step-by-step reproduction instructions | ||
<!-- | ||
Please list the steps needed to reproduce the bug. For example: | ||
1. Go to '...' | ||
2. Click on '...' | ||
3. Scroll down to '...' | ||
--> | ||
|
||
## Expected behaviour | ||
<!-- Please describe what you expected to happen. --> | ||
|
||
## Actual behaviour | ||
<!-- Please describe what actually happened. --> | ||
|
||
## Screenshots or screen recording (optional) | ||
<!-- | ||
If possible, please upload a screenshot or screen recording which demonstrates | ||
the bug. You can use LIEcap to create a GIF screen recording: | ||
https://www.cockos.com/licecap/ | ||
--> | ||
|
||
## Code snippet (optional) | ||
<!-- | ||
If this bug is to related to a developer API, please share a code snippet that | ||
demonstrates the issue. | ||
For small snippets paste it directly here, or you can use GitHub Gist to share | ||
multiple code files: https://gist.github.com | ||
Please ensure the shared code can be used by a developer to reproduce the | ||
issue—ideally it can be copied into a local development environment or executed | ||
in a browser console to help debug the issue. | ||
--> | ||
|
||
## WordPress information | ||
- WordPress version: <!-- e.g. "5.6.0". Find this in Tools → Site Health → Info → WordPress --> | ||
- Are all plugins except HRS Blocks deactivated? <!-- "Yes" or "No" --> | ||
- Are you using the HRS child theme? <!-- "Yes" or "No" --> | ||
|
||
## Device information | ||
- Device: <!-- e.g. "Desktop" or "iPhone 11" --> | ||
- Operating system: <!-- e.g. "Windows 10" or "iOS 14" --> | ||
- Browser: <!-- e.g. "Chrome 86.0" or "Mobile Safari" --> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,74 @@ | ||
# Contributing and Maintaining | ||
|
||
Thanks for contributing! | ||
|
||
The following guidelines outline how to contribute and provide instructions about our workflow and release processes. | ||
|
||
## Ways to contribute | ||
|
||
Contributing includes reporting problems with the plugin, suggesting improvements or new features, or submitting pull requests with new code. All contributions are managed here on GitHub. Here are some ways you can help: | ||
|
||
### Reporting bugs | ||
|
||
If you run into an issue with the plugin, please take a look through [existing issues](https://github.com/washingtonstateuniversity/wsuwp-plugin-hrs-courses/issues) and [open a new one](https://github.com/washingtonstateuniversity/wsuwp-plugin-hrs-courses/issues/new/choose) if needed. If you're able, include steps to reproduce, environment information, and screenshots/screencasts as relevant. | ||
|
||
### Suggesting enhancements | ||
|
||
New features and enhancements are also managed via [issues](https://github.com/washingtonstateuniversity/wsuwp-plugin-hrs-courses/issues/new/choose). Select "Feature request" and complete the form as applicable. | ||
|
||
### Pull requests | ||
|
||
Pull requests represent a proposed solution to a specified problem. They should always reference an issue that describes the problem and contains discussion about the problem itself. Discussion on pull requests should be limited to the pull request itself, i.e. code review. | ||
|
||
## Documenting changes | ||
|
||
### Commits | ||
|
||
Commits should be small, individual items of work. They should focus distinctly on one type of change and be separate from other features. Each commit must include a short (no more than 70 characters) commit message summarizing the change. A longer description is optional. | ||
|
||
### Semantic Versioning & Human-friendly Changelogs | ||
|
||
We follow the [Semantic Versioning pattern](https://semver.org/) when assigning version numbers. Each version number must have three digits (including zero) in the <major>.<minor>.<patch> format, where: | ||
|
||
We follow the [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) standard when maintaining changelogs. | ||
|
||
## Workflow | ||
|
||
The `develop` branch is the development branch, which means it contains the next version to be released. The `stable` branch contains the current latest release. Always work on the `develop` branch and open pull requests against `develop`. | ||
|
||
### `Stable` and `Develop` branches | ||
|
||
The stable branch stores the official release history, while the develop branch serves as an intermediary between feature branches and stable. All branches – except hotfixes – are branched off of develop instead of stable. | ||
|
||
Changes should never be pushed directly to the stable branch. New features should be branched off of develop and, when complete, merged back into develop using a non-fast-forward merge. | ||
|
||
### Develop on `feature` branches | ||
|
||
Create a new branch from develop for development work. Feature branches should be given short names prefixed with the appropriate label for the type of change they introduce, such as `fix/name-of-issue` or `enhancement/update-to-feature`. We have a minimal set of labels, which we’ll add to and clean up as needed: | ||
|
||
- fix: Correct something that isn’t worked. | ||
- feature: A new feature. | ||
- enhancement: Modification of existing functionality or features. | ||
- documentation: Improvement or addition to documentation. | ||
- dependencies: Changes to dependency files. | ||
- management: Updates to project-level settings. | ||
|
||
Make frequent, small commits to the feature branch. Frequently check develop against the feature branch to keep up with changes other developers are working on. When finished with the feature, merge the feature branch back into develop using a non-fast-forward merge (--no-ff): `git checkout develop && git merge --no-ff <label>/<feature-name>`. | ||
|
||
### Deploying with `release` branches | ||
|
||
When the develop branch is ready to be merged into stable as a new release, create a new `release/<version>` branch off of develop. In the `release/<version>` branch you will: | ||
|
||
1. First bump version numbers to `<version>-rc.1`. | ||
1. Update the changelog in CHANGELOG.md. | ||
1. Update documentation. | ||
1. Push the release branch to GitHub and create a pre-release targeting the release branch. Tag the pre-release `v<version>-rc.1`, title it `<version> RC 1` and copy the Changelog contents for the release into the description. | ||
1. Use the release branch and the build RC 1 version to run tests and fix bugs. No new features will be added on this branch. | ||
1. Once testing is finished, increment the version numbers again, to `<version>`, and update the changelog and any other docs if changes were made during testing. | ||
1. Open a new pull request to merge `release/<version>` into stable. Title it `<version>` and complete the PR template as needed. When the pull request is ready, non-fast forward merge it into stable (or select “Merge pull request” in GitHub): `git checkout stable && git merge --no-ff release/<version> && git push origin stable` | ||
1. Create a new release in GitHub targeting the stable branch. Tag the release `v<version>`, title it `<version>`, and copy the Changelog contents for the release into the description. | ||
1. Last, merge stable back into develop with a --no-ff merge so that it contains any changes made on the release branch. | ||
|
||
### Emergency patching with `hotfix` branches | ||
|
||
Critical maintenance and fixes are implemented thorugh hotfix branches. These are the only branches made directly off the stable branch. They operate much like release branches, but their parent is the stable branch instead of develop. As soon as the fix is complete it is merged into stable and a new release is made. Then stable is merged into develop to keep both up to date. |
Oops, something went wrong.