WordPress/two-factor

Release version 0.8.0

jeffpaul opened this issue · 10 comments

jeffpaul commented

Release instructions

  • Branch: Starting from master, create a branch named release/0.8.0 for the release-related changes.
  • Version bump: Bump the version number in readme.txt and two-factor.php if it does not already reflect the version being released. Update both the plugin "Version:" header value and the plugin TWO_FACTOR_VERSION constant in two-factor.php.
  • Changelog: Add/update the changelog in readme.txt.
  • New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
  • 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.
  • Create Release PR: Push any local changes in release/0.8.0 to origin, create a release PR, and request review to ensure all CI checks pass and ensure master branch changes are limited to merges only.
  • Merge: After review approval, merge the release pull request (or make a non-fast-forward merge from your release branch to master). master contains the latest stable release.
  • Release: Create a new release, naming the tag and the release with the new version number, and targeting the master branch. Paste the changelog from readme.txt into the body of the release and include a link to the closed items on the milestone.
  • SVN: Wait for the GitHub Action: Deploy 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.
  • Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/two-factor/. This may take a few minutes.
  • Close the milestone: Edit the milestone with the release date (in the Due date (optional) field) and link to the GitHub release (in the Description field), then close the milestone.
  • Punt incomplete items: If any open issues or PRs which were milestoned for 0.8.0 do not make it into the release, update their milestone to 0.9.0 or Future Release.
jeffpaul commented

@iandunn I've opened this issue to try and document what I see as the release steps for the plugin (this is based off 10up's default plugin release instructions which we've iterated a bit on and while perhaps not fully descriptive is helpful to try and eliminate human error in forgetting specific steps). I would suggest that as part of the release that I add a version of this to readme.md for anyone looking to handle a future release (perhaps alongside the Deployments section). Also curious if you feel any steps above should be updated before I start the release process?

@kasparsd also curious from your perspective handling prior releases if you would recommend any updates to the proposed release process documented in the issue here?

kasparsd commented

This looks great!

On some projects I've added this kind of checklist to the pull request template. I'm not sure if GitHub has enabled a selector for templates if there are multiple, though https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository

Push: Push your master branch to GitHub (e.g. git push origin master).

We should probably ensure that this happens via a pull request merge on GitHub to ensure that (1) all CI checks pass and (2) we're able to lock down the master branch to merges only.

  • 👍1
iandunn commented

That sounds good to me, I ❤️ checklists 🙂

master contains the latest stable release.

It seems like we treat master as the dev branch, and use tags for the stable releases. Is this just intended to mean that "at this moment in time, master is identical with the latest stable release (but won't always be)"?

FYI that it looks like the automated sync to SVN is disabled, so we may have to do some of that manually, or identify and fix whatever caused it to be disabled.

jeffpaul commented

@kasparsd as far as I know, there's only a single PR template that can be added. We could have an issue template that was specific for releases though, so if you think that's helpful (either paired with detailing the steps in the readme.md or in place of that) then I can include that in a separate PR.

Push: Push your master branch to GitHub (e.g. git push origin master).

We probably won't need this step as the step prior merges the release PR to master and that paired with tagging and releasing on GH should trigger the GH Action to deploy the release to WP.org.

Alternatively, we could shift to creating a develop branch here as the default branch and only merge to master (or maybe rename that to trunk or main while we're at it) during a release (a workflow similar to how we tend to operate at 10up).

  • 👍1
jeffpaul commented

@iandunn if there's no resolution on fixing the current GH Action for deploys, we could switch to the GH Action that 10up uses (and >2k others do as well). Happy to open a PR to do that, but note that there's no construct there that would deploy a merge to master with no corresponding release on GH as a straight push to trunk on SVN as currently is set up in the 2FA GH Action for deploys to WP.org.

  • 👍1
jeffpaul commented

@kasparsd @iandunn any concerns with me proceeding here or would you like any additional tweaks to the release checklist? Also, any other comments/concerns on my two comments above in response to your initial feedback?

kasparsd commented

Yes, this looks good as long as we’re only allowing merges to the main branch through passing pull requests.

  • 👍1
iandunn commented

That all sounds good to me 👍🏻

  • 👍1
jeffpaul commented

FYI that I opened #543 to try and help resolve the disabled/failing Deploy action.

kasparsd commented

The release appears to have run successfully and committed the latest code to SVN https://github.com/WordPress/two-factor/actions/runs/4530719131/jobs/7980001698 with the following changeset https://plugins.trac.wordpress.org/changeset/2887448