Skip to:
Content
Pages
Categories
Search
Top
Bottom
Codex Home → Prelaunch Checklist

Prelaunch Checklist

Releasing BuddyPress to the world is a big deal, and takes quite a few manual steps to ensure safe & comfortable updates & upgrades are had by all. Below are the steps release leads go through with each & every release.

Note: These steps vary slightly depending on major/minor/urgency of the deployment to WordPress.org. For questions, or if something is not clear, please ping @johnjamesjacoby, @boone, or @djpaul, who are mad enough to comprehend how & why all this works the way it does. (We keep planning to automate this, but until then, please enjoy this extremely long and intimidating list of responsibilities.)

Prologue

There are two code repositories, and you’ll be tasked with compiling the BuddyPress codebase from the development repo to the deployment repo. They are separate because BuddyPress is deployed to almost all end-users from the public WordPress.org plugin repository in a way that requires some development assets to be pre-compiled (it’s not a literal 1-to-1 copy) and because BuddyPress is lucky enough to have its own Trac instance on WordPress.org.

Key

We’ll refer to these two repositories like this for the duration of these steps:

[dev] = buddypress.svn.wordpress.org
[wporg] = plugins.svn.wordpress.org/buddypress/

Now that you’re familiar, sit back, relax, put on your headgear, and get ready for a trip to the atmosphere…

Pre-Release Codex, Trac, & Publicity

For minor/major full releases only.

  1. Create release version page on codex (https://codex.buddypress.org/releases/version-1-5-5/)
  2. Create version page to codex Releases page (https://codex.buddypress.org/releases/).
  3. Review recent rockstars and release credits (props). Change as needed.
  4. Updates to bp-about page.
  5. Draft blog post.
  6. If this is a major release, check to see whether there are tickets closed against a minor release that will not happen due to the major release. (For example, 3.3.0 was subsumed into 4.0.0.) If so, reassign those tickets to the major release milestone, and delete the unused milestone.

Version Bumps (in dev)

  1. Change version in bp-loader.php (plugin header)
  2. Change version in src/bp-loader.php (plugin header)
  3. Change $this->version (setup_globals()) in class-buddypress.php
  4. Change stable-tag readme.txt (major and minor releases)
  5. Change tested-up-to readme.txt (major and minor releases)
  6. Change version in package.json
  7. Use the latest version of npm and: npm install and then npm shrinkwrap
  8. Add “Upgrade Notice” & “Changelog” entries for this version in readme.txt (major and minor releases)
  9. Commit changes

Tagging/Branching (in dev)

N.B. Once created, a tag cannot be removed or edited nor trunk merged to it so please ensure all necessary updates to trunk are committed before creating the tag copy from it.

Deploying to [wporg]

You’ll probably want to checkout the entire BuddyPress repository from WordPress.org. This way you can navigate the entire trunk/branches/tags structure, and more easily make changes as necessary.

svn co https://plugins.svn.wordpress.org/buddypress/

Omit externals – that will save you lots of time. Checkout into a temporary directory…

  1. Export the development version of BuddyPress you intend to deploy to users: svn co https://buddypress.svn.wordpress.org/tags/2.7.1/ . --force --ignore-externals.
  2. Use the latest version of npm and run: npm install and then composer install && grunt build. (You may need to globally update npm, or other such fun stuff. Your mileage may vary.)
  3. Overwrite the contents of the trunk directory with the contents of build in the [wporg] checkout.
  4. If it’s a beta or a release candidate, make sure the Stable tag in both trunk and the newly created tag are the same and are the one of current stable version of BuddyPress.
  5. Run svn stat to check if you need to svn add or svn delete files
  6. Create an svn tag from trunk using svn cp trunk tags/2.7.1 .
  7. If it’s not a beta or a release candidate, make sure the Stable tag in both trunk and the newly created tag are the same and are the one of the new version of BuddyPress. This is needed to make sure GlotPress will successfully update Translation strings.
  8. Commit & cross fingers!
  9. Verify the zip file for the tag, which will be at a URL of the format https://downloads.wordpress.org/plugins/buddypress.4.0.0.zip
  10. Ask Paul Gibbs to update https://github.com/buddypress/BuddyPress-build (via git-svn he has locally).
  11. Ask Boone Gorges to go to https://packagist.org/packages/buddypress/buddypress and click “Update”.

Trac cleanup

  1. If any tickets remain in milestone, close them or reassign them to a future milestone.
  2. Close milestone.
  3. Ensure that milestone exists for next major and minor releases.
  4. Create a Version for the completed release.

Announcements

  1. Publish blog post on buddypress.org
  2. Update version number in the Downloads page on the buddypress.org.
  3. Write a blog post on bpdevel.wordpress.com
  4. Forum announcement in buddypress.org/support
  5. Send tweets from the BP twitter accounts.

Version Bumps (in dev)

  1. If a major x.y release, bump trunk version numbers to alpha in bp-loader.php (2.1-alpha).
  2. Bump relevant branch version numbers to alpha in bp-loader.php (2.1-alpha).
  3. If a major x.y release, sync [dev] trunk and [wporg] trunk.

GlotPress Translation Strings

Contents

Article Contributors

18
Paul Wong-Gibbs
11
Hugo Ashmore
10
Boone Gorges

Updated 5 years ago / Published 10 years ago

Want to help?

The BuddyPress Codex is volunteer-powered, which means you can contribute too! If you're interested in updating existing articles or creating entirely new ones, please read our Codex Standards & Guidelines.

Skip to toolbar