Release checklist

[alindeman]

• [ ] Draft blog post (?)
• [x] Checkout the latest code and get bundles current
  • rake change_branch[master]
• [x] Update changelogs in all repos
  • Add version number and URL to each README
  • rake 'git:commit[Updates changelog for vX.Y.Z [ci skip]]'
  • rake git:push
• [x] Update version number in all repos
  • rake 'gem:write_version[X.Y.Z]'
  • rake 'git:commit[Releases X.Y.Z]'
• [ ] Release gems
  • rake gem:release
• [ ] Branch X-Y-maintenance in all repos (if first X.Y release)
  • rake 'git:checkout[-b X-Y-maintenance]'
  • Update maintenance-branch file in each
  • rake 'git:commit[Updates maintenance-branch file [ci skip]]'
  • rake "run[git push origin X-Y-maintenance -u]"
• [ ] Update docs
  • rake 'relish[X.Y]' (exclude .Z). To run this you need relish push access.
  • rake 'update_docs[X.Y, X-Y-maintenance]'. To run this you need rspec.github.io in your repos directory, with the source branch checked out.
• [ ] Update version to X.Y+1.pre in master.
  • rake 'git:checkout[master]'
  • rake 'gem:write_version[X.Y+1.pre]'
  • rake 'git:commit[Bump version...]'
  • rake git:push
• [ ] Publish blog post
  • Use rake version_stats[vX.(Y - 1).0...vX.Y] to get version stats for post.
  • Put changelog release notes into blog post.
  • Run middleman deploy from rspec.github.io checkout to deploy to staging and TARGET=prod middleman deploy for a prod deploy.
• [ ] Tweet from @rspec account
• [ ] Notify mailing list (link to the blog post)

[myronmarston]

I think there's a bit of an open question around rspec 2.99: do we release it at the same time as rspec 3, or do we release it in advance (potentially weeks in advance) of rspec 3?

My two cents: I hard originally planned rspec 2.99 to be released at the same time as 3.0, but some folks may want to start the upgrade process ahead of time, and as long as we're 100% sure we're not going to be making any more breaking changes in 3.0 (and 2.99 has all deprecation notices it needs) I think it's OK to release ahead of time.

[dchelimsky]

and as long as we're 100% sure

Alarm bells ringing! I strongly recommend avoiding anything that backs us into any corner on this. How about releasing alphas, betas, RCs, and finals of 2.99 and 3.0 in (relative) tandem?

[dchelimsky]

Note that Travis build may fail due to timing

It's happened every release that I've done, and it's been a frustration that I've simply accepted. Does anybody know if github has an API for turning hooks on and off? If so, maybe we could automate a task that turns off travis integration for all repos, pushes all repos, turns travis integration back on and invokes the webook.

[myronmarston]

Alarm bells ringing! I strongly recommend avoiding anything that backs us into any corner on this. How about releasing alphas, betas, RCs, and finals of 2.99 and 3.0 in (relative) tandem?

I've been planning on doing betas, RCs, etc...the main question is whether we hold off releasing 2.99 final until we're ready to release 3.0 final.

[myronmarston]

It's happened every release that I've done, and it's been a frustration that I've simply accepted. Does anybody know if github has an API for turning hooks on and off? If so, maybe we could automate a task that turns off travis integration for all repos, pushes all repos, turns travis integration back on and invokes the webook.

Honestly, this doesn't particularly bother me. If someone wants to look into this, that's great but I don't think it's very important.

[JonRowe]

We should probably utilise this issue at some point hey.

[myronmarston]

I've used it as a checklist for the beta releases.

[JonRowe]

:+1: :)

[cupakromer]

Any reason we're keeping this one open?

[myronmarston]

Well, I use it as a checklist when I do releases :). Doesn't have to remain open for that, though.