Ignore:
Timestamp:
Mar 16, 2012, 6:18:19 AM (8 years ago)
Author:
Peter
Message:

remove trailing whitespace

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/README.developer

    r2500 r2711  
    55We follow the coding style described in
    66[http://cbbp.thep.lu.se/~jari/documents/c++_coding_guidelines/index.html C++ coding guidelines]
    7 [http://cbbp.thep.lu.se/~jari/documents/c++_coding_guidelines/c++_coding_guidelines.pdf pdf] 
     7[http://cbbp.thep.lu.se/~jari/documents/c++_coding_guidelines/c++_coding_guidelines.pdf pdf]
    88[http://cbbp.thep.lu.se/~jari/documents/c++_coding_guidelines/c++_coding_guidelines.ps postscript]
    99with the additions described here.
     
    1414(`make` and `make check`) when someone makes a clean checkout. There
    1515is a short introduction to subversion and its usage available as
    16 [http://cbbp.thep.lu.se/~jari/documents/subversion_guidelines/index.html Subversion guidelines]. 
     16[http://cbbp.thep.lu.se/~jari/documents/subversion_guidelines/index.html Subversion guidelines].
    1717We follow these guidelines.
    1818
     
    7474}}}
    7575
    76 or similarly 
     76or similarly
    7777
    7878{{{
     
    9696
    9797Helper functions and classes that are not part of yat API should either be
    98 labeled with doxygen flag `\internal` or placed in sub-namespace `detail`. 
     98labeled with doxygen flag `\internal` or placed in sub-namespace `detail`.
    9999
    100100= Build =
     
    103103
    104104To build from a subversion checkout, you will need GNU Autotools. More
    105 specifically 
     105specifically
    106106 * Automake 1.11 (or later), http://www.gnu.org/software/automake/
    107107 * Autoconf 2.63 (or later), http://www.gnu.org/software/automake/
     
    133133= Versioning =
    134134
    135 We use a softened version of 
     135We use a softened version of
    136136[http://apr.apache.org/versioning.html APR guidelines] which in short implies
    137137
     
    142142backwards."''
    143143
    144 == '''`MAJOR`''' Releases == 
     144== '''`MAJOR`''' Releases ==
    145145
    146146No compatibility is guaranteed between '''`MAJOR`''' versions.
     
    150150'''`MINOR`''' versions should be compatible with earlier minor
    151151versions. However, in the `0.x` line we may allow exceptions to this
    152 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. 
    153  
     152rule, 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.
     153
    154154== '''`PATCH`''' Releases ==
    155155
    156156Versions with same '''`MAJOR.MINOR`''' are perfectly compatible,
    157157forwards and backwards.
    158  
     158
    159159This implies that only implementations can be modified in a `PATCH`
    160160release. You cannot change the API, not even add functions or
     
    181181Backward Binary Compatibility means that an application that has been
    182182compiled against version `x.y` can be linked against version
    183 `x.y+1`. 
     183`x.y+1`.
    184184
    185185Specifically this implies:
Note: See TracChangeset for help on using the changeset viewer.