-
Notifications
You must be signed in to change notification settings - Fork 14
HowTo: Publish new version
Hans Morbach edited this page May 22, 2024
·
3 revisions
The following steps should be done shortly before release to avoid merge conflicts
- From master, create a new branch titled release/* where you replace the * with the next version number of the plugin (e.g. release/2.9.2 )
- Open up the milestone for the version that you are about to release and use the linked issues and pull requests to create the changelog for the next version
- Update the changelog in the readme.txt file, do not forget to add the date of the release
- In the newly created branch, update the readme.txt with the new version number under "Stable Tag"
- Also update commonsbooking.php and change "Version" in the header of the file as well as further down the value in the constant COMMONSBOOKING_VERSION
- Empty the COMMONSBOOKING_VERSION_COMMENT Constant
- Make sure, that 100% of the strings are translated into German, you can use the little green checkmark to see the result of the checks
- The entry "E2E Tests / i18n-coverage (push)" should show "100%"
- If there are strings missing, push them on the release branch and check again for 100% coverage
The release/* branch will automatically create a zip file of the plugin as it will appear on WordPress.org
- Click on the little green checkmark and view the details of the "Build zip from release branch" action, under "Summary" you can download a zip of the built plugin as an artifact
- Upload the zip file to your staging environment and check if everything is working as expected
-
When everything is in order, create a new release in GitHub and point it to the release branch
-
Name the tag just like the version you are going to publish (e.g. 2.9.2). Do NOT prepend a v to the versioning (e.g. v.2.9.2). The tag on WordPress.org must match what is present in the readme.txt
-
Publish the release and the release action will pick up from there
-
Confirm the release on WordPress.org using the link in the email
- Merge the release/* branch that you just created back into master using a pull request
- Close the existing milestone for the version you just released
- Create a new milestone with the next upcoming minor version