Document issue management and release processes

[smichel17]

I'm not sure exactly where I want to put this, so for now I'm dumping it into an issue here. None of it is that complicated, but it's nice to document it anyway.

GitHub Issues

I've found that trying to plan any farther ahead than whatever I'm literally working on right now never works out. Those plans quickly become out of date, and then I have to "waste" time updating the labels/milestones to reflect the new plans. So, instead of planning, labels and milestones document the current state of issues. I use the standard set of GitHub labels and two milestones:

1. someday/maybe is for issues with a poor return on effort spent, and thus I'm unlikely to ever do them. However, they're still good ideas, so I don't want to close them, either; I would accept a pull request implementing them.
2. next release is for things that are either completed, waiting to be released or that I'm currently working on (ie, will shortly be completed); when I start working on an issue, I'll add it to this milestone.

Changelogs

Changelogs work pretty much the same way. It's a bit of duplicate effort, but not too much.

• The main changelog is located at app/src/main/assets/changelog.md
• Much like the next release milestone, there's an 'Unreleased' section at the top.
• Any user-facing commit should add relevant entries to the 'Unreleased' section

Release Process

1. Make a commit that:
   • Bumps the version number and version code in build.gradle.
     • The changelog will help with deciding whether it should be a major, minor, or bugfix version.
   • Renames the 'Unreleased' section of the changelog to reflect the new version number, and add a link to the diff at the bottom (this won't exist yet, since it hasn't been tagged).
   • Copies the contents of that section into app/src/main/play/listings/en-US/whatsnew.txt for display on F-Droid and Google Play.
2. Tag that commit with the appropriate version number and make a GitHub release
   • The release contents are another place to copy the same section of the changelog
   • This will prompt an F-Droid release
3. Update Github milestones
   • Rename the next release milestone to the release version (eg, v3.1.0), close it, and create a new milestone named next release to repeat the process for the next release.
4. Do a release on Google Play
   • @raatmarien has been doing this, not me. Thus, I'm not sure how recent the latest release is.
   • Also, the Play store listing is broken (people can't purchase the app) due to a payment configuration issue on our end. See #148.
   • We've talked about transferring Red Moon to my GPlay Developer account, but haven't gotten around to it yet.
   • This is mostly configured so that it could be done automatically with Triple-T Gradle Play Publisher; I'm not sure if that's how it's currently done.