Changes between Version 19 and Version 20 of StartModMaint

Timestamp:

Dec 13, 2013, 6:17:27 PM (9 years ago)

Author:

Beman Dawes

Comment:

--

StartModMaint

@@ -71 +71 @@
 }}} 
 
-=== Fix a simple bug ===
+=== Fix a simple bug directly on {{{develop}}} ===
 
 For simple bugs, particularly in projects with a single maintainer, it is common practice to fix bugs directly in the {{{develop}}} branch. Creating a test case with your favorite editor, testing the test case, fixing the bug, testing the fix, and then iterating if necessary is no different than with any programming environment.
@@ -83 +83 @@
 }}}
 
-=== Fix a bug using a bug-fix branch ===
-
-Fixing a bug directly on the {{{develop}}} branch is fine, if that's the library's policy, but if the bug is messy, multiple maintainers are involved, interruptions are expected, or other complexities are present, then it is better practice to work on the bug in a separate bug-fix branch.
-
-{{{
-git checkout -b bugfix/complex-boo-boo
-}}}
-
-This creates the branch {{{bugfix/complex-boo-boo}}}, and switches to it. Incidentally, {{{bugfix/}}} is part of the name, not a directory specifier. The new branch is based on branch {{{develop}}} because the working copy was on branch {{{develop}}} at the time of the branch.
+There are some significant disadvantages to this simple approach:
+* The fix is now made to {{{develop}}} but you must remember to merge it to a release branch or directly to {{{master}}}. It is very easy to forget to do that merge, particularly if this is a mature library you are not working with very often.
+* Users who need the bug fix right away are forced to jump through hoops to retrieve the fix from {{{develop}}}.
+
+Putting out a point release solves both of those problems. Read on...
+
+=== Fix a bug using a hot-fix branch ===
+
+Fixing a bug directly on the {{{develop}}} branch is fine, if that's the library's policy, but if the bug is messy, multiple maintainers are involved, interruptions are expected, or other complexities are present, then it is better practice to work on the bug in a separate branch. And doing that on a hot-fix branch solves the problems mentioned at the end of the prior section.
+
+The operational distinction between a bug-fix branch and a hot-fix branch is that a bug-fix branch is branched from {{{develop}}} and then at completion merged back to {{{develop}}}, while a hot-fix branch is branched from {{{master}}} and then at completion is merged to both {{{master}}} and {{{develop}}}. With either approach, the branch is deleted after it has been merged. 
+
+{{{
+git checkout master
+git checkout -b hotfix/complex-boo-boo
+}}}
+
+This creates the branch {{{hotfix/complex-boo-boo}}}, and switches to it. Incidentally, {{{hotfix/}}} is part of the name, not a directory specifier. The new branch is based on branch {{{master}}} because the working copy was on branch {{{master}}} at the time of the branch.
 
 Since the bug is complex, it may take some time to fix and may go through several cycles of fixes, tests, and commits.
 
-Once the bug is fixed and a final commit is done, then it is time to merge the {{{bugfix/complex-boo-boo}}} branch back into {{{develop}}}:
-
-{{{
+Once the bug is fixed and a final commit is done, then it is time to merge the {{{hotfix/complex-boo-boo}}} branch into {{{master}}} and {{{develop}}}:
+
+{{{
+git checkout master
+git merge hotfix/complex-boo-boo
+git push
 git checkout develop
-git merge bugfix/complex-boo-boo
-git push
-}}}
-
-The usual practice is to delete temporary branches like {{{bugfix/complex-boo-boo}}} once they have been merged:
-
-{{{
-git branch -d bugfix/complex-boo-boo
-}}}    
- 
+git merge hotfix/complex-boo-boo
+git push
+git branch -d hotfix/complex-boo-boo
+}}}
+
 === Start work on a new feature ===