Changes between Version 7 and Version 8 of Guidlelines

Show
Ignore:
Author:
mickecarlsson (IP: 81.227.48.213)
Timestamp:
10/07/10 01:03:55 (3 years ago)
Comment:

Fixed spelling errors

Legend:

Unmodified
Added
Removed
Modified

  • Guidlelines

    v7 v8  
    1 '''These are the guidleines that ALL Developers with SVN Checkin Access Should follow''' 
     1'''These are the guidelines that ALL Developers with SVN Checkin Access Should follow''' 
    22 
    3 1. '''ALWAYS''' test a change before comitting back to SVN. Even the trivial can break things and should be tested.[[BR]][[BR]] 
     31. '''ALWAYS''' test a change before committing back to SVN. Even the trivial can break things and should be tested.[[BR]][[BR]] 
    44 
    552. '''NEVER''' check-in code if you know it is going to break things. See rule 3 for alternatives.[[BR]][[BR]] 
    66 
    7 3. Large complex changes, rewrites, etc. should be kept in your working directory or done in a temporary branch until reasonable testing efforts indiicate it is working and ready to be made available in trunk. Large can be a bit of a judgment call. It may involve a major rewrite, something that touches several different files, or just something that your own judgment says may need a bit more testing and is likley to break things.[[BR]][[BR]] 
     73. Large complex changes, rewrites, etc. should be kept in your working directory or done in a temporary branch until reasonable testing efforts indicate it is working and ready to be made available in trunk. Large can be a bit of a judgment call. It may involve a major rewrite, something that touches several different files, or just something that your own judgment says may need a bit more testing and is likely to break things.[[BR]][[BR]] 
    88 
    994. Try to put useful comments when you checkin. Think CHANGELOG which is what gets generated from here. Comments like ''"oops"'' and ''"thanks joe"'' don't say much in a change log. Comments like ''"fixes #1323, thanks joe"'' will allow you to get back to the bug, but are still not great for a change log. Comments like ''"fixes #1323, wrong callerid on extensions with display names using <> format"'' give the reader of a changelog at least something to go by (or just copy the bug description). And then of course, lots more detail about the bug is always welcome if you feel like writing it up.[[BR]][[BR]]