About this Page

Minx is not a large project. In all likelihood, I will be the only developer and its only user (well, there may be at most a handful of others who might use it). Given that, 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

dev1.x 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 dev1.x. When the feature is done, the branch will be merged onto dev1.x and then, usually, closed.

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

Release-only Artifacts

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

Hotfixes

If we find a bug on rel1.x that needs an urgent fix, we will branch off off dev1.x at the point where that particular release was made, apply the fix on this "hotfix" branch and then merge the hotfix branch to both dev1.x and rel1.x (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, version numbering API, etc.) solely on rel1.x without accidentally getting them onto a development branch (where they do not belong).

Making a Release

1. Merge from dev1.x to rel1.x.
2. Build and test.
3. Build API docs and check-in.
4. Replace all ckout in docs with rel1.x.
5. Update wiki/changelog.wiki and wiki/relnotes.wiki.
6. Update News section of wiki/home.wiki plus any other docs that need updating.
7. Update version number in minxlib/version.cc 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 minxlib/version.cc).
8. Push to chiselapp.