Changeset 2711

Timestamp:

Mar 16, 2012, 6:18:19 AM (11 years ago)

Author:

Peter

Message:

remove trailing whitespace

File:

• trunk/README.developer (modified) (9 diffs)

trunk/README.developer

@@ -5 +5 @@
 We follow the coding style described in
 [http://cbbp.thep.lu.se/~jari/documents/c++_coding_guidelines/index.html C++ coding guidelines]
-[http://cbbp.thep.lu.se/~jari/documents/c++_coding_guidelines/c++_coding_guidelines.pdf pdf] 
+[http://cbbp.thep.lu.se/~jari/documents/c++_coding_guidelines/c++_coding_guidelines.pdf pdf]
 [http://cbbp.thep.lu.se/~jari/documents/c++_coding_guidelines/c++_coding_guidelines.ps postscript]
 with the additions described here.
@@ -14 +14 @@
 (`make` and `make check`) when someone makes a clean checkout. There
 is a short introduction to subversion and its usage available as
-[http://cbbp.thep.lu.se/~jari/documents/subversion_guidelines/index.html Subversion guidelines]. 
+[http://cbbp.thep.lu.se/~jari/documents/subversion_guidelines/index.html Subversion guidelines].
 We follow these guidelines.
 
@@ -74 +74 @@
 }}}
 
-or similarly 
+or similarly
 
 {{{
@@ -96 +96 @@
 
 Helper functions and classes that are not part of yat API should either be
-labeled with doxygen flag `\internal` or placed in sub-namespace `detail`. 
+labeled with doxygen flag `\internal` or placed in sub-namespace `detail`.
 
 = Build =
@@ -103 +103 @@
 
 To build from a subversion checkout, you will need GNU Autotools. More
-specifically 
+specifically
  * Automake 1.11 (or later), http://www.gnu.org/software/automake/
  * Autoconf 2.63 (or later), http://www.gnu.org/software/automake/
@@ -133 +133 @@
 = Versioning =
 
-We use a softened version of 
+We use a softened version of
 [http://apr.apache.org/versioning.html APR guidelines] which in short implies
 
@@ -142 +142 @@
 backwards."''
 
-== '''`MAJOR`''' Releases == 
+== '''`MAJOR`''' Releases ==
 
 No compatibility is guaranteed between '''`MAJOR`''' versions.
@@ -150 +150 @@
 '''`MINOR`''' versions should be compatible with earlier minor
 versions. However, in the `0.x` line we may allow exceptions to this
-rule, if developers agree the gain of change is sufficient. Binary compatibility is typically not guaranteed between '''`MINOR`''' versions. The `YAT_LT_VERSION` in [source:trunk/build_support/version.m4 version.m4] should reflect which versions are binary compatible. 
- 
+rule, if developers agree the gain of change is sufficient. Binary compatibility is typically not guaranteed between '''`MINOR`''' versions. The `YAT_LT_VERSION` in [source:trunk/build_support/version.m4 version.m4] should reflect which versions are binary compatible.
+
 == '''`PATCH`''' Releases ==
 
 Versions with same '''`MAJOR.MINOR`''' are perfectly compatible,
 forwards and backwards.
- 
+
 This implies that only implementations can be modified in a `PATCH`
 release. You cannot change the API, not even add functions or
@@ -181 +181 @@
 Backward Binary Compatibility means that an application that has been
 compiled against version `x.y` can be linked against version
-`x.y+1`. 
+`x.y+1`.
 
 Specifically this implies: