29 lines
		
	
	
		
			1.4 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			29 lines
		
	
	
		
			1.4 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| SNMP::Info Developer Guidelines
 | |
| 
 | |
| Coding Guidelines:
 | |
|     - tab-width of 4, no tab characters
 | |
|     - keep POD documentation up-to-date
 | |
|     - always update ChangeLog before committing
 | |
|     - check-in required mibs to netdisco-mibs and release new package if needed
 | |
| 
 | |
| Release and Testing Instructions: 
 | |
|     - Please see misc/RELEASE in Netdisco
 | |
|       ( http://netdisco.cvs.sourceforge.net/viewvc/netdisco/misc/RELEASE?view=markup )
 | |
|       and follow all testing and release guidelines
 | |
| 
 | |
| FAQ:
 | |
|     - Do I have to update the version number and timestamp in modified files before committing? 
 | |
|     -> No.  These are RCS tags that are automatically updated by CVS when you commit
 | |
| 
 | |
|     - Should I add changes at the top of the ChangeLog?
 | |
|     -> Yes. The changelog is created one commit at a time.  If there isn't a
 | |
|         section for the current version, then add one at the top and put your
 | |
|         changes after.  You can leave the date field for the release empty (). 
 | |
| 
 | |
|     - What should I change the $VERSION to?
 | |
|     -> If you are the first person to get to a file after a release, update it
 | |
|        to either  release++ or "release++ dash cvs".   
 | |
|        Example: File is marked 2.01, change it to 2.02-cvs with your new changes.
 | |
|        Example: File is marked 2.02-cvs,  no change until packaging for release when the -cvs is removed.
 | |
|        TODO: Is there still an odd/even scheme as introduced by Eric?
 |