-
Notifications
You must be signed in to change notification settings - Fork 36
Admin: Creating a Release
When preparing a new release, there are several tasks that must get done.
Typically this will be most but not all content in the dev branch. By announcing a planned release 4 or 5 days before we release it, we give the team more time to focus on completing any incomplete events in dev and debugging any buggy events.
Take a look at the issue tracker, particularly the "Next Beta" and/or "Next Stable" milestones, for any outstanding issues that would affect the next release. Determine whether the associated content will be fixed, removed, or ignored.
Our releases are accompanied by both release notes and a changelog. These have generally been written by Malthus & Tuttu. Looking through closed issues and the commit history can be helpful in creating a changelog. UPDATE Version check event.
Check who the coders, writers, translators, etc were for everything in the changelog. Make sure all team members appear in the team member list, and make sure anyone not in the team who added an idea we used gets added to that list.
Checkout the beta or stable branch as appropriate to the release. Merge in the relevant content. If everything in dev is to be included, this is a simple git merge dev. If some things in dev are not going to be released, you may find it helpful to first create a temporary branch, delete the unwanted files in this branch, and then merge this temporary branch into the release branch. Alternatively, you might checkout the release branch and then use git checkout dev -- [files] to add just the listed files from dev into the checked out branch. Often this is more tedious, but can be helpful in some cases.
Note that access to the beta and stable branches is limited to repo admins. I have invited all the Admins as repo admins, but not everyone has accepted their invitation. Also, if necessary, current admins can invite new admins under the Settings/Collaborators & Teams tab of the repo. Probably preferable to limit this to admins unless someone else is needed, but if they are needed this is how to add them.
In, particular, whoever's making the release (Malthus for Steam, often Tuttu for forums) needs to know what branch it's in.
Use python copy_english.py from the command line in the mod's root directory to copy English into non-translated languages. You will need Python installed and set up to do this. You may wish to manually adjust partially-translated files; see commit d8c49cc for an example of how this might work. That said this can be a huge pain and may be more trouble than it's worth. Ignoring partial-translation issues or deleting partially translated files before running copy_english so the script replaces them with English are potential alternatives.
It's nice to know what exact commit we released, so create a branch with git checkout -b v1.#(.#) or a tag with git tag v1.#(.#). This should be done with the exact code we release.
It's generally nice to revert any localization patches you made with git revert [commit #]. Once this is done, check out the master branch and merge it to here, since the most recent release is generally where you want people to start developing new features from.