trunk: as of 23 March 2007, reserved for Leopard (version 3.5+) development
I realized soon after creating this branch that it was actually a mistake for two reasons:
- It really should have been a Jaguar branch, not a Panther branch, as the software on the branch continued to support versions of Mac OS X back to Jaguar.
- The branch was created too soon.
I created the branch because I wanted to keep my Leopard development separate from my legacy development. The branch was made too soon (too far ahead of Leopard’s release) because most of the work ended up taking place on the branch instead of on the trunk. The trunk remained almost motionless and I periodically merged in changes from the branch; I may as well have just done all development on the trunk and only branched later on.
Towards the end of March 2007 and in conjunction with the move to SVK I executed the following plan:
- Keep the 3.1 series as the Jaguar-compatible branch.
- The next major version will be 3.5 and that will most likely be for Leopard development; it will coincide with the trunk.
- The poorly named Panther branch will be allowed to die off; I may even choose to delete it.
- Let 3.1.1 be the last public release before the branch.
- After that branch, use SVK because it handles branching and merging better.
- SVK makes branch management so much easier that it makes sense to branch more often; instead of branching only major OS-compatibility cut-off points it becomes attractive to branch at every minor release. In many cases where you currently would only consider using tags it may make sense to create branches instead. For example, a branch for the 3.2 series, 3.3 series, and so on. This makes it easy to roll out bug-fix releases (3.2.1 etc). In fact, SVK branches are so lightweight and easy that you can even consider making local-only branches for minor bug-fixes (that don’t even correspond to full releases); these branches never exist separately in the remote repository, but once the work is completed the changes get merged in upstream.