checklist for releases

[aschweigert]

We need a much better process for releases of Largo because way too many things are slipping through.

This is the start of a checklist, Iet's add to this and make sure we've captured everything that needs to be done to ensure we ship stable, quality code.

The owner of the release needs to complete the following steps BEFORE merging to master and tagging the release:

• run the theme check plugin and address any outstanding issues
• using WP sample data, go through the entire theme unit tests checklist
• design checklist tktk (add to the list of theme unit tests, including style guidance, patterns that need to be followed, etc., eventually this will be codified in the INN/Largo style guide)
  • click around: don't just visually check the homepage, but also internal pages
• move any outstanding issues to future milestones or backlog
• resolve all secret issues, private issues, or issues with the theme that are otherwise documented outside of this public repository
• update the changelog
• release announcement blog post written and saved as draft
• update all version numbers

tag release, close milestone

After release is tagged:

• recompile LESS on all child themes
• new release needs to be deployed to our sites - largo-umbrella, inndev, other standalone instances (wisconsin, etc.)
• notify non-INN sites
• publish launch announcement blog post
• update version number on largo.inn.org, like in Bump the Largo version number to 0.5.5.4 in all references on largo.inn.org INN/umbrella-inndev#36

[0aveRyan]

Another one for After release is tagged:

• tweet announcement and schedule 2-5 for the next 7 days (TweetDeck, HootSuite) with simple download prompt or "Newsroom Staff Pages should be clean and useful. We think so too. See Largo 0.X's new....". Make sure they get cross-tweet'd between INN accounts.

[benlk]

For majorly-different all child themes, run through the child theme Largo-version update checklist and make sure that everything is okay.

Especially check the following types of themes

• having a Gruntfile
• anything in partials/

Especially check the following themes:

• npq
• wisconsin
• mwen
• invw
• se energy
• Voice of OC

[benlk]

For plugin changes:

• grab latest db dump
• make change
• see what breaks

Do we have/should we look into a script that occasionally screenshots all member sites and does a visual diff, to catch times when widgets disappear?

[aschweigert]

not a bad idea to keep some kind of reference for that unless we can figure out some way for WP to tell us if a widget is disappeared because of something we changed

[benlk]

This checklist may find the following command useful for finding files duplicated in child themes:

cd wp-content/themes/
find . -iname "your-file-here.php" -print

For finding duplicated function definitions:

grep -r "function function_name" .

[MirandaEcho]

The owner of the release needs to complete the following steps BEFORE merging to master and tagging the release:

• run the theme check plugin and address any outstanding issues
• using WP sample data, go through the entire [theme unit tests checklist]
• design checklist tktk (add to the list of theme unit tests, including style guidance, patterns that need to be followed, etc., eventually this will be codified in the INN/Largo style guide)
  • click around: don't just visually check the homepage, but also internal pages
• move any outstanding issues to future milestones or backlog
• resolve all secret issues, private issues, or issues with the theme that are otherwise documented outside of this public repository
• update the changelog
• release announcement blog post written and saved as draft
• update all version numbers
• tag release, close milestone
• run through the child theme Largo-version update checklist and make sure that everything is okay.

After release is tagged:

• recompile LESS on all child themes
• new release needs to be deployed to our sites - largo-umbrella, inndev, other standalone instances (wisconsin, etc.)
• notify non-INN sites
• publish launch announcement blog post
• update version number on largo.inn.org, like in Bump the Largo version number to 0.5.5.4 in all references on largo.inn.org INN/umbrella-inndev#36
• tweet announcement and schedule 2-5 for the next 7 days (TweetDeck, HootSuite) with simple download prompt or "Newsroom Staff Pages should be clean and useful. We think so too. See Largo 0.X's new....". Make sure they get cross-tweet'd between INN accounts.

For plugin changes:

• grab latest db dump
• make change
• see what breaks

[benlk]

0.6.1 version: #1590

0.6.2 version: #1690

0.6.3 version: #1694

[benlk]

New in #1705 is the intention to:

• after a release, for example 0.6.4, bump the 0.5-dev version number to include -prerelease: 0.6.5-prerelease.
• after any significant work in Largo that will be deployed to a client site, add .1 to the prerelease number: 0.6.5-prerelease.1 then becomes 0.6.5-prerelease.2, and that version number is what gets deployed to the client site.
• continue incrementing until we tag 0.6.5
• changelog.md remains bundling things under a 0.6.5 header