Skip to content
Geoff Goehle edited this page May 29, 2014 · 5 revisions

The current setup is to have the three branches listed at Branching and Release Model:

  • master
  • release/x.y
  • develop There may be other branches occasionally. These are "feature" branches for things which are too big to be merged into develop all at once from a private repo.

Merging release/x.y into develop

If the git protocol has been followed correctly, master should always be behind release/x.y. However, to keep things sane we allow release/x.y to get ahead of develop. Periodically someone should make a pull request which merges release/x.y into develop. This will get any hotfixes from master into develop, as well as any changes made to release/x.y. It may be necessary to fix conflicts when merging release/x.y into develop. When this happens you can do one of two things:

  • Create a local copy of develop, and pull in release/x.y. If the conflicts are easy to fix, then fix them yourself, check that the changes work, and push your local copy of develop to the openwebwork repository. (This is one of the only times you should push directly from your machine to the openwebwork repsoitory.)
  • Create a feature branch tracking develop, pull in release/x.y, and fix the conflicts. Now push this feature branch to your personal repository and create a pull request for that feature branch to develop. This should be done when the conflicts are substantial and you feel like your merge needs extra review. (Because of the way merges work it is impossible to only show the changes you made to fix the conflicts. You can highlight these changes using a line comment if you like.)

Releasing a new WeBWorK version

When it is time to release version x.y you should do the following.

  1. Make a new tag for master called WeBWorK-x.(y-1)+. (This is a tag for the previous version plus all of its hotfixes.)

  2. Create a pull request from release/x.y into master. (This is basically the only time that something which is not based off master should be pulled into master.)

  3. Merge the pull request. (We do this using the web interface to leave behind a clear trail of evidence.)

  4. Make a new tag for master called WeBWorK-x.y

  5. Check everything out and make sure things still work. In particular check that the version numbers got updated properly.

  6. Merge release/x.y into develop to make sure that develop is completely up to date. There may be conflicts that you need to fix for this pull. (See above.)

  7. Wait a few days and then delete the release/x.y branch from the repository.

Creating a Release Branch

It is fine for the repository to operate without a release branch for a while. However the next time that develop is in a reasonable state a new release/x.y branch should be created from develop. As long as people have been properly reviewing pull requests this should be relatively easy.

  • Create a new branch called release/x.(y+1) tracking develop on your machine.
  • Change the version number from "develop" to "x.(y+1)".
  • Push release/x.(y+1) to the openwebwork repository.