Merging into master Branch

Updated 876 Days AgoPublic

Actions

About every two to four weeks we strive for a merge into the master branch, following the release approach of git-flow. The merges are tagged and accompanied by change logs. We follow a strict protocol for master merges:

1. Determine the name of the merge
   1. Look up the current week number (ISO-8601): https://www.epochconverter.com/weeknumbers
   2. Look up the weeks of the current month and choose the best fitting description:
      • Very Early <Month>
      • Early <Month>
      • Mid <Month>
      • Late <Month>
      • Very Late <Month>
   3. The naming scheme is <Year> Week <Week> (<Description>)
   4. For the rest of this protocol, we exemplarily use 2020 Week 39 (Late September)
2. For now, create an empty Phriction page for the changelog
   1. The URI scheme is https://phabricator.mitk.org/w/mitk/changelog/2020.39/
   2. The title is 2020 Week 39 (Late September)
3. Create (and assign) an MITK task for the merge
   1. The title is 2020 Week 39 (Late September)
   2. The description is a link to the changelog in Remarkup format: [[mitk/changelog/2020.39]]
4. Create a release branch
   1. For all following git actions you must be a member of the MITK Elevated Branching Privileges group
   2. Look up CDash to identify the most recent green commit in the develop branch
   3. Create and checkout release branch: git checkout -b release/T<n>-2020-Week-39 <commit>
   4. Push release branch: git push -u origin release/T<n>-2020-Week-39
   5. The push will execute a git hook that writes a table into the task containing all merge commits, associated tasks and revisions (Phabricator Differentials) since the last master merge
5. Write the changelog
   1. Use the generated table in the task mentioned above to write the changelog in Phriction
   2. Use earlier changelogs as template
6. Merge the release branch
   1. Merge the release branch into the master branch
      1. Change the commit message to the remarkup formatted changelog text without the {icon arrow-left} Previous changelog • Next changelog {icon arrow-right} navigation helpers at the top and bottom, but prepended by the Merge commit preamble snippet below (Example on GitHub)
      2. Eventually merge it into the master branch: git checkout master && git merge --no-ff release/T<n>-2020-Week-39
   2. Tag the merge commit with the current date
      1. git tag -a snapshots/2020-09-25
      2. See the Snapshot tag message snippet below for the two-line tag message
7. Push the master branch including the snapshot tag
   1. git push && git push origin snapshots/2020-09-25
8. Merge the master merge commit back into the develop branch
   1. Instead of merging the release branch back into the develop branch, merge the master merge commit back into the develop branch to make the snapshot tag available there as well
   2. git checkout develop && git pull && git merge --no-ff master && git push
9. Delete the remote release branch
   1. git push origin --delete release/T<n>-2020-Week-39
10. Add the latest changelog to the Changelog page
    1. Move the previous changelog to the top of the list in the Past changes section
    2. Set the latest changelog in the Recent changes section
    3. Update the Next changelog links at the top and (!) bottom of the previous changelog
    4. For the current changelog, the Next changelog link should point to itself until another changelog is published
11. Close the release task as Resolved

2020 Week 39 (Late September)

The following - possibly updated - changelog can be viewed as formatted
article at https://phabricator.mitk.org/w/mitk/changelog/2020.39/.

<insert changelog here>

2020 Week 39 (Late September)
https://phabricator.mitk.org/w/mitk/changelog/2020.39/