Development Process
Not logged in

About this Page

Morg is not a large project. In all likelihood, I will be the only developer and its only user. Thus, the project is not well-served by a heavy-duty process and nor does it have one. However, there is some method to the madness...


Development and Branching Policy

dev is the main development branch. Usually, development will proceed linearly on this branch. However, if there are others contributing to the project and/or there is a major feature that will continue for a while, we will create feature branches off off dev. When the feature is done, the branch will be merged onto dev and then, usually, closed.

rel is the release branch. When we are ready to make a release, we will merge from dev and then tag (after tweaking as required).

Release-only Artifacts

There are certain things that live only on the release branch. For example, the changelog, release notes, and so on. These things are never merged into the development branches. Consequently, no development ever occurs on the rel branch. We only merge to rel, never from it to dev or some other branch.

Hotfixes

If we find a bug on rel that needs an urgent fix, we will branch off off dev at the point where that particular release was made, apply the fix on this "hotfix" branch and then merge the hotfix branch to both dev and rel (tagging the release by increasing the version number's patch level).

Although this approach is a little more complicated and results in a slightly messier revision history, it allows us to maintain certain release-only items (changelog, release notes, etc.) solely on rel without accidentally getting them onto a development branch (where they do not belong).


Making a Release

  1. Merge from dev to rel.
  2. Test.
  3. Replace all ckout in docs with rel.
  4. Update wiki/changelog.wiki and wiki/relnotes.wiki.
  5. Update News section of wiki/home.wiki plus any other docs that need updating.
  6. Update version number in py/morg.py and commit --tag as vA.B.C (where major number A, minor number B, and patch level C all match the new version number assigned in the code).
  7. Push to chiselapp.