[plcrashreporter.wiki] push by - Edited wiki page VersioningStandards through web user interface. on 2013-02-13 17:30 GMT

[codesite...@google.com]

Revision: 4e8c1774388e
Author: landon.j.fuller <landon....@gmail.com>
Date: Wed Feb 13 09:30:27 2013
Log: Edited wiki page VersioningStandards through web user interface.
http://code.google.com/p/plcrashreporter/source/detail?r=4e8c1774388e&repo=wiki

Modified:
/VersioningStandards.wiki

=======================================
--- /VersioningStandards.wiki Wed Feb 13 09:29:45 2013
+++ /VersioningStandards.wiki Wed Feb 13 09:30:27 2013
@@ -43,11 +43,11 @@

While the requirements for feature branches are not quite as rigorous as
master, you should still take care to commit stable and unit tested code
(use TDD!). Bugs you don't implement are bugs you don't have to find later,
and our test-driven approach is intended to minimize the number of bugs
that occur, even on feature development branches.

-Feature branches should be named as follows: <username>-[issue
#]-<descriptive name>
+Feature branches should be named as follows: `<`username`>`-`[`issue
#`]`-`<`descriptive name`>`

For example:
- landonf-54-addr-remap
- landonf-mach-exceptions
+ * landonf-54-addr-remap
+ * landonf-mach-exceptions

As a general rule, branches should have associated issues attached to
them. In practice -- especially with development spread across several
issue trackers and organizations -- this may not be viable.