[plcrashreporter.wiki] push by - Typos! on 2013-02-13 17:47 GMT

1 view
Skip to first unread message

codesite...@google.com

unread,
Feb 13, 2013, 12:47:32 PM2/13/13
to plcrashrepo...@googlegroups.com
Revision: cb65a0fb203f
Author: landon.j.fuller <landon....@gmail.com>
Date: Wed Feb 13 09:47:25 2013
Log: Typos!
http://code.google.com/p/plcrashreporter/source/detail?r=cb65a0fb203f&repo=wiki

Modified:
/VersioningStandards.wiki

=======================================
--- /VersioningStandards.wiki Wed Feb 13 09:42:30 2013
+++ /VersioningStandards.wiki Wed Feb 13 09:47:25 2013
@@ -34,13 +34,13 @@

== HEAD / Master ==

-The HEAD (or 'trunk') branch tracks current development state of the
project, including changes that have seen only limited testing. Commits
made to this branch may not be sufficiently tested for release, but they
must be in a presumed-stable state, and must include unit test coverage and
API documentation.
+The HEAD (or 'master') branch tracks current development state of the
project, including changes that have seen only limited testing. Commits
made to this branch may not be sufficiently tested for release, but they
must be in a presumed-stable state, and must include unit test coverage and
API documentation.

Commits made to master _should not_ introduce breaking changes to file
formats or encodings. Those changes should be considered, discussed, and
approved on an issue-specific feature branch (see below).

== Feature Branches ==

-Feature branches are used to track in-progress development of features (or
bug fixes) that may have a destabilizing effort on the code base, cases
where APIs may not yet be finalized, or potentially breaking changes to
serialization formats.
+Feature branches are used to track in-progress development of features (or
bug fixes) that may have a destabilizing effect on the code base, cases
where APIs may not yet be finalized, or potentially breaking changes to
serialization formats.

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.

Reply all
Reply to author
Forward
0 new messages