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:
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.
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
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.
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
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.
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.
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:
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.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.
app/src/main/assets/changelog.md
next release
milestone, there's an 'Unreleased' section at the top.Release Process
build.gradle
.app/src/main/play/listings/en-US/whatsnew.txt
for display on F-Droid and Google Play.next release
milestone to the release version (eg, v3.1.0), close it, and create a new milestone namednext release
to repeat the process for the next release.