[minor edits / cross referencing welcome here, but copy-paste your changes before submitting in case of multiple people trying to simultaneously make edits and be careful not to overwrite changes made by others - for additions, or deletions?, leave comments below and we'll discuss before adding to the master list]

Timeline for things that need to happen in a specific order:

• finish the remaining breaking/feature items on the 0.5.0 milestone
  1. SSH support in Pkg: SSH support in Pkg #16041, PR at LibGit2: build libgit2 with libssh2 support #17391 - assignees = Art, Keno, and myself
  2. safe non-traditional array indexing: Safe non-traditional array indexing #16973, (possibly stale?) PR at Make unvetted size throw an error for arrays with non-1 indexing #17228 - assignees = Tim, Jeff, core team for feedback
• announce feature freeze by changing VERSION from 0.5.0-dev to 0.5.0-pre feature freeze master #17503
  • master becomes (temporarily) locked for anything other than bugfixes (preferably release-critical ones, anything not absolutely critical can potentially wait until backporting for 0.5.1), doc fixes or test additions
• create release-0.5 branch, change master VERSION from 0.5.0-pre to 0.6.0-dev to reopen master for breaking changes
  • this could happen immediately after the feature freeze step, but unless progress towards breaking 0.6 changes is inconveniently blocked here we might want to wait a short time
• at this point commits should not be made directly to the release-0.5 branch without prior discussion, the branch will operate in release mode:
  1. bugfixes should be made as usual via PR's to master first, wherever applicable there
  2. if you think something is a backport candidate, ask about it with a comment, we will have some discussion and decide yes or no on backporting during the RC process
  3. a contributor will mark the issue/PR with the backport pending 0.5 label, or ping the @juliabackports user in a comment (which sends a message to https://groups.google.com/forum/#!forum/julia-backports which we will monitor) if there's a needed commit to master without an associated issue/PR number (we should almost always avoid doing that)
  4. backporting changes should be done as follows:
     • git checkout release-0.5
     • git pull
     • git checkout -b $USER/backport-foo
     • git cherry-pick -x -e SHA
     • Edit the commit message to add "ref #..." so the cross-reference link shows up to the associated issue/PR.
     • Open a pull request targeted against the release-0.5 branch (there's a github dropdown menu on the open PR page) so CI runs. Please add [release-0.5] to the title of the PR so it's more obvious that the PR is against the release branch and not master.
     • If we have a lot of these, I will handle the backporting myself with a series of rollup pull requests to lessen the CI load.
• when the last RC1-critical cleanup items (see below) are finished, we tag v0.5.0-rc1, build binaries, and announce to the mailing lists
  • automatic windows code signing is not working right now on the buildbots, so this will have to be done manually on a windows machine by someone who has access to the certificates - probably me
  • any users and package authors who've been waiting to test their code and update their packages for 0.5 should do so
  • the most recent RC will be available under Travis language: julia as a julia: 0.5 option and AppVeyor with an 0.5-latest url, but release will not change until 0.5.0 final is tagged
• repeat the last few steps in the process, targeting 1 RC per week, until we're satisfied with being ready to tag v0.5.0 final.
  • I'll probably handle most of the backports at this stage, and run PackageEvaluator on the proposed changes to make sure we don't introduce regressions between successive RC's
• tag v0.5.0 final, celebrate, 🎆 🍻 etc, get 0.6 going and onwards towards 1.0, world domination
  • bugfix backport 0.5.x releases will happen at a target of one per month, as we've been doing
  • change VERSION on release-0.5 branch to 0.5.1-pre

Things that can happen at any time but need to be done (help welcome!) before RC1:

• remaining NEWS and doc additions for Stringapalooza, threads, IOContext [Doc] Documentation for IOContext required #16763 and all other breaking changes, deprecations, and major feature additions and performance changes that users should know about (e.g. startup time on Windows, LLVM version, debugger availability, iterator traits HasLength() is the default iteratorsize for all custom iterators? Even if they don't define length? (Breaks Collect) #15977, docs for collect() are incorrect #17439, etc)
• deprecations still not in NEWS like deprecate print_escaped, print_unescaped, and print_joined #16603 and many others (done in NEWS: move breaking changes earlier, add a few deprecations #17779)
• make sure CI, buildbots, and tests in both source builds and binary installs are all happy with the final set of changes (linux binaries need rpath errors #17602 (comment) fixed prior to 0.5.0 final to get rid of a warning when libgfortran is not installed system-wide)
• make sure make release-candidate passes and checklist will all work, and keep it that way (doctests etc)
• fix final important straggler bugs, e.g. Pkg.checkout issues, deciding what to do about ARM/Power breakage (maybe use a different LLVM version but only on those architectures, if that's the best fix)

Things that can start now but will go on between RC1 and v0.5.0 final:

• fixing broken packages! see http://pkg.julialang.org/pulse.html, there's a lot of work to do to bring the ecosystem to a state where it works as well on 0.5 as it does on 0.4 right now
• identifying and fixing any release-blocking bugs that we don't know about yet and/or can't fix before we decide to tag RC1
• review parts of the documentation that aren't tested by doctests and make sure they're up to date (moved from rc1 to ongoing)
• review issues and PR's (both open and closed) marked with needs-docs and needs-tests and rectify any we can (moved from rc1 to ongoing)

The later pieces of this have been my policy for release management ever since the 0.3.x backports and 0.4 RC's, which has been working pretty well from my impression. Feedback on this is welcome, and I'll be turning these items into a formal written release/backporting policy document going forward.