Merge branch 'develop'

CHANGELOG.md

@@ -13,6 +13,14 @@ All notable changes to this project will be documented in this file, per [the Ke
 ### Security
 -->
 
+<!-- ... -->
+## [1.5.0] - 2024-08-01
+
+### Added
+* Add Button to Timestamp current webpage screenshot by @michael-sumner in #32
+* Add WooCommerce Support to readme.txt file by @michael-sumner in #31
+* Limit readme.txt file to 5 Tags by @michael-sumner in #30
+
 <!-- ... -->
 ## [1.4.1] - 2024-06-29
 
@@ -85,6 +93,7 @@ All notable changes to this project will be documented in this file, per [the Ke
 - Initial plugin release
 
 [Unreleased]: https://github.com/scoredetect/timestamps/compare/trunk...develop
+[1.5.0]: https://github.com/scoredetect/timestamps/compare/1.4.1...1.5.0
 [1.4.1]: https://github.com/scoredetect/timestamps/compare/1.4.0...1.4.1
 [1.4.0]: https://github.com/scoredetect/timestamps/compare/1.3.1...1.4.0
 [1.3.1]: https://github.com/scoredetect/timestamps/releases/tag/1.3.1

CONTRIBUTING.md

@@ -26,11 +26,11 @@ The `develop` branch is the development branch which means it contains the next
 
 ## Release instructions
 
-Open a [new blank issue](https://github.com/scoredetect/timestamps/issues/new) with `[Release] X.Y.Z`, then copy and paste the following items, replacing version numbers and links to the milestone.
+Open a [new blank issue](https://github.com/scoredetect/timestamps/issues/new) with `[Release] 1.5.0`, then copy and paste the following items, replacing version numbers and links to the milestone.
 
-- [ ] 1. Branch: Starting from `develop`, cut a release branch named `release/X.Y.Z` for your changes.
+- [ ] 1. Branch: Starting from `develop`, cut a release branch named `release/1.5.0` for your changes.
 - [ ] 2. Version bump: Bump the version number in `timestamps.php`, `package.json`, `package-lock.json`, `readme.txt`, and any other relevant files if it does not already reflect the version being released. In `timestamps.php` update both the plugin "Version:" property and the plugin `SDCOM_TIMESTAMPS_VERSION` constant.
-- [ ] 3. Changelog: Add/update the changelog in `CHANGELOG.md`, ensuring to link the [X.Y.Z] release reference in the footer of `CHANGELOG.md` (e.g., https://github.com/scoredetect/timestamps/compare/X.Y.Z-1...X.Y.Z).
+- [ ] 3. Changelog: Add/update the changelog in `CHANGELOG.md`, ensuring to link the [1.5.0] release reference in the footer of `CHANGELOG.md` (e.g., https://github.com/scoredetect/timestamps/compare/1.5.0-1...1.5.0).
 - [ ] 4. Props: Update `CREDITS.md` file with any new contributors, confirm maintainers are accurate.
 - [ ] 5. Readme updates: Make any other readme changes as necessary. `README.md` is geared toward GitHub and `readme.txt` contains WordPress.org-specific content. The two are slightly different.
 - [ ] 6. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in `.distignore`.
@@ -42,7 +42,7 @@ Open a [new blank issue](https://github.com/scoredetect/timestamps/issues/new) w
 - [ ] 12. [Check the _Build and Tag_ action](https://github.com/scoredetect/timestamps/actions/workflows/build-and-tag.yml): a new tag named with the version number should've been created. It should contain all the built assets.
 - [ ] 13. Release: Create a [new release](https://github.com/scoredetect/timestamps/releases/new):
   * **Tag**: The tag created in the previous step
-  * **Release title**: `Version X.Y.Z`
+  * **Release title**: `Version 1.5.0`
   * **Description**: Release changelog from `CHANGELOG.md` + `See: https://github.com/scoredetect/timestamps/milestone/#?closed=1`
 - [ ] 14. SVN: Wait for the [GitHub Action](https://github.com/scoredetect/timestamps/actions/workflows/push-deploy.yml) to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
 - [ ] 15. Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/timestamps/. This may take a few minutes.
@@ -51,9 +51,9 @@ Open a [new blank issue](https://github.com/scoredetect/timestamps/issues/new) w
 
 There may be cases where we have an urgent/important fix that ideally gets into a release quickly without any other changes (e.g., a "hotfix") so as to reduce (1) the amount or testing before being confident in the release and (2) to reduce the chance of unintended side effects from the extraneous non-urgent/important changes.  In cases where code has previously been merged into `develop` but that ideally is not part of a hotfix, the normal release instructions above will not suffice as they would release all code merged to `develop` alongside the intended urgent/important "hotfix" change(s).  In case of needing to release a "hotfix" the following are the recommended steps to take.
 
-1. Branch: Starting from `main`, cut a hotfix release branch named `hotfix/X.Y.Z` for your hotfix change(s).
+1. Branch: Starting from `main`, cut a hotfix release branch named `hotfix/1.5.0` for your hotfix change(s).
 1. Version bump: Bump the version number in `timestamps.php`, `package.json`, `readme.txt`, and any other relevant files if it does not already reflect the version being released.  In `timestamps.php` update both the plugin "Version:" property and the plugin `SDCOM_TIMESTAMPS_VERSION` constant.
-1. Changelog: Add/update the changelog in `CHANGELOG.md` and `readme.txt`, ensuring to link the [X.Y.Z] release reference in the footer of `CHANGELOG.md` (e.g., https://github.com/scoredetect/timestamps/compare/X.Y.Z-1...X.Y.Z).
+1. Changelog: Add/update the changelog in `CHANGELOG.md` and `readme.txt`, ensuring to link the [1.5.0] release reference in the footer of `CHANGELOG.md` (e.g., https://github.com/scoredetect/timestamps/compare/1.5.0-1...1.5.0).
 1. Props: Update `CREDITS.md` file with any new contributors, confirm maintainers are accurate.
 1. Readme updates: Make any other readme changes as necessary.  `README.md` is geared toward GitHub and `readme.txt` contains WordPress.org-specific content.  The two are slightly different.
 1. New files: Check to be sure any new files/paths that are unnecessary in the production version are included in `.distignore`.