Release Process

Steps to perform around a release:

1. Make sure everything is done on the master branch, all issues for the current milestone are closed, performance has not regressed, all issues and PRs that have been closed during the development phase have been tagged with the release milestone, there are no closed issues or PRs in the Next Tasks milestone, documentation is up to date etc. so we are ready for release
2. In your own Skosmos git repo, make sure you are up to date and on the master branch: git checkout master && git pull
3. Make sure package dependencies are up to date and installable without any breakage: php composer.phar self-update && php composer.phar update
4. Create a new maintenance branch and switch to it: git checkout -b v2.15-maintenance && git push origin v2.15-maintenance
5. Test that the maintenance branch works in staging (log on to finto-web-kk, cd to /var/www/staging.finto.fi): git pull && git checkout v2.15-maintenance && php composer.phar self-update && php composer.phar update && apachectl restart and go to staging.finto.fi to see that the new release of Skosmos is running okay
6. Commit additional patches to the maintenance branch if necessary
7. Update the Upgrading page and check other wiki documentation possibly affected by the release, e.g. InstallTutorial
8. When everything is fine, make a release from the maintenance branch using the GitHub Releases UI: Tag version "v2.15", target branch is the v2.15-maintenance branch you just created, the title is "Skosmos 2.15", enter the release notes, and press Publish
9. Announce the release on skosmos-users: copy the text from the GitHub release page into a new post
10. Upgrade the production install (finto.fi) to the new release, using the same process as for staging in step 5: log on to finto-web-kk, cd to /var/www/finto.fi (make sure to also migrate new configuration directives, custom CSS changes, headers and footers etc.). Do not checkout to the master branch!
11. At your own dev environment: Switch your working directory back to the master branch: git checkout master
12. At your own dev environment: Create an empty commit to detach master from the maintenance branch: git commit --allow-empty -m "mark the start of 2.16 development"
13. Push the commit to GitHub: git push
14. Add a tag to mark the beginning of a new development cycle: git tag v2.16-dev
15. Push the new tag to GitHub: git push --tags
16. Adjust milestones: mark the completed milestone as closed and create a new one for the next cycle
17. In this document, change the version numbers for the next release

Backporting fixes to the maintenance branch

1. Make sure you're up to date and switch to the maintenance branch: git pull && git checkout v1.2-maintenance
2. Go through the list of commits on the master branch and cherry-pick the ones you want to have: git cherry-pick -x 7bd1a30a629992fd5c400b0d05e785cdb24f43aa
3. Push your changes to GitHub: git push
4. Test that the maintenance branch works in staging: git pull && git checkout v1.2-maintenance && php composer.phar self-update && php composer.phar update --no-dev && apachectl restart
5. Commit additional patches to the maintenance branch if necessary
6. Upgrade the production installs to the new release
7. When you have a suitable set of fixes, make a maintenance release using the GitHub UI