﻿.. -*- coding: utf-8-with-signature -*-

=================
Release Checklist
=================

meejah produced this list while making the 1.15.0 release. Many of the
things in the `how_to_make_a_tahoe-lafs_release.org` document aren't
relevant anymore. However, until we are sure that a "new release list"
is correct and works, I don't just want to completely revise it.

A major difference here is splitting into things that "any
contributer" can do and things that contributers with possibly more
access need to do.

So, follow *this* list for 1.16.0 and if it seems complete, we should
delete the older checklist after that.

Any Contributor
---------------

Anyone who can create normal PRs should be able to complete this
portion of the release process.


Prepare for the Release
```````````````````````

The `master` branch should always be releasable. However, it is worth
asking on appropriate channels (IRC, the mailing-list, Nuts and Bolts
meetings) whether there are interesting changes that should be
included (or NOT included) etc.

- Create a ticket for the release in Trac
- Ticket number needed in next section


Create Branch and Apply Updates
```````````````````````````````

- Create a branch for release-candidates (e.g. `release-1.15.0-rc0`)
- run `tox -e news` to produce a new NEWS.txt file (this does a commit)
- create the news for the release
  - newsfragments/<ticket number>.minor
  - commit it
- manually fix NEWS.txt
  - proper title for lastest release (instead of "Release ...post1432")
  - double-check date
  - spot-check the release notes (these come from the newsfragments
    files though so don't do heavy editing)
  - commit these changes
- update "relnotes.txt"
  - update all mentions of 1.14.0 -> 1.15.0
  - update "previous release" statement and date
  - summarize major changes
  - commit it
- update "CREDITS"
  - are there any new contributers in this release?
  - one way: git log release-1.14.0.. | grep Author | sort | uniq
  - commit it
- update "docs/known_issues.rst" if appropriate
- update "docs/INSTALL.rst" references to the new release
- Push the branch to github
- Create a (draft) PR; this should trigger CI (note that github
  doesn't let you create a PR without some changes on the branch so
  running + commiting the NEWS.txt file achieves that without changing
  any code)
- Confirm CI runs successfully on all platforms


Create Release Candidate
````````````````````````

Before "officially" tagging any release, we will make a
release-candidate available. So there will be at least 1.15.0-rc0 (for
example). If there are any problems, an -rc1 or -rc2 etc may also be
released. Anyone can sign these releases (ideally they'd be signed
"officially" as well, but it's better to get them out than to wait for
that).

Typically expert users will be the ones testing release candidates and
they will need to evaluate which contributers' signatures they trust.

- (all steps above are completed)
- sign the release
  - git tag -s -u 0xE34E62D06D0E69CFCA4179FFBDE0D31D68666A7A -m "release Tahoe-LAFS-1.15.0-rc0" tahoe-lafs-1.15.0-rc0
  - (replace the key-id above with your own)
- build all code locally
  - these should all pass:
    - tox -e py27,codechecks,docs,integration
  - these can fail (ideally, they should not of course):
    - tox -e deprecations,upcoming-deprecations
- build tarballs
  - tox -e tarballs
  - ls dist/
  - confirm a "*1.15.0-rc0*" file exists



Privileged Contributor
-----------------------

Steps in this portion require special access to keys or
infrastructure. For example, **access to tahoe-lafs.org** to upload
binaries or edit HTML.

Hack Tahoe-LAFS
```````````````

Did anyone contribute a hack since the last release? If so, then
https://tahoe-lafs.org/hacktahoelafs/ needs to be updated.



