KMyMoney2 Project Handbook

Dipl.Ing. Thomas Baumgart

Michael Edwardes

As for any software development project, certain rules regulate the development process of KMyMoney2. These rules cover things like coding standards, configuration management and error reporting, just to name a few. The focus of this document is on configuration management and coding standards. More information about the KMyMoney2 project can be found on the project's hompage.

If you have any comments to raise about this document please send an email to , the project's developer mailing list and we will try to rectify it. Please note that the most up-to-date version of this document can be found in the source tree and is online on the project's homepage. A PDF version is also available for download.

A prerequisite for this document is a basic understanding on the work with CVS. Even though this document covers some of the more special topics of CVS in more detail it is not intended as an introduction to CVS in general.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover texts, and with no Back-Cover Texts. A copy of the license is included in the appendix entitled "GNU Free Documentation License".


Table of Contents
1. Configuration Management
1.1. Version Control Tool
1.2. Access to the repository
1.2.1. Read-Only access
1.2.2. Read-Write access
1.3. Version management
1.3.1. Layout of the version numbers
1.3.2. Creating a new version
1.3.3. Creating a new stable version
1.4. Version controlled files
1.4.1. Files that must be stored in the repository
1.4.2. Files that should not be stored in the repository
2. Release Management
2.1. Tar Ball
2.1.1. KDevelop
2.1.2. Shell
2.1.3. Size optimization for tar-ball
2.2. Creating an RPM file
2.2.1. Copying the tar-ball to the RPM structure
2.2.2. Test building
2.2.3. Setting up the SPEC file
2.2.4. Building the package
2.2.5. Testing the package
2.2.6. Signing the package
3. Coding Rules
3.1. General
3.2. Header Files
3.3. Source Files
4. Unit Testing
4.1. Why unit testing?
4.2. Unit testing in KMyMoney2
4.3. Unit testing HOWTO
4.3.1. Integration of CPPUNIT into the KMyMoney2 project
4.3.2. Naming conventions
4.3.3. Necessary include files
4.3.4. Accessing private members
4.3.5. Standard methods for each testcase
4.3.6. CPPUNIT_ASSERT
4.3.7. CPPUNIT_FAIL
4.3.8. CPPUNIT_TEST_SUITE
4.3.9. CPPUNIT_TEST_SUITE_END
4.3.10. CPPUNIT_TEST
4.3.11. CPPUNIT_TEST_SUITE_REGISTRATION
5. Problem Management
5.1. Reporting problems
5.1.1. Referencing problems
5.2. Problem attributes
5.2.1. Reported By
5.2.2. Severity level
5.2.3. Area
5.2.4. Assignee
5.2.5. Status
5.2.6. Resolution
A. CVS examples
A.1. Checking out from the repository
A.2. Checking in to the repository
A.3. Updateing changes performed by other developers
A.4. Dismissing changes
A.5. Keeping different branches on the same machine
A.6. Promoting bug-fixes to the main branch
A.7. Creating a new stable release
B. Source and Header Examples
B.1. Header File Example
B.2. Source File Example
C. Unit Test Examples
C.1. Unit Test Header File Example
C.2. Unit Test Source File Example
C.3. Unit Test Container Source File Example
D. RPM SPEC file example
E. Licence
E.1. Free Documentation Licence
List of Tables
1-1. Definition of version control related terms
5-1. Available problem status values
5-2. Available problem resolution values
List of Examples
1-1. Revisions on the head of a stable branch
3-1. Using include stoppers
3-2. Including other header files
3-3. Class declaration
3-4. Complete class declaration
3-5. Declaration of slot and signal methods
3-6. Attribute naming convention
3-7. Including header files in source files
3-8. Method implementation
3-9. Kernighan & Ritchie flow control style
3-10. Allman flow control style
3-11. One line body flow control style
3-12. Local variable nameing convention
A-1. Filling the sandbox for the first time
A-2. Filling the sandbox for the first time with a specific version
A-3. Promote changes to the repository
A-4. Updating the sandbox
A-5. Checking the status of files in the sandbox
A-6. Reverting changes made to the sandbox
A-7. Keeping stable and development branch on one machine
A-8. Checking out the stable branch for the first time
A-9. Promoting a change from the release to the development branch
A-10. Creating a new stable branch