Development guidelines

From World Wind Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 06:46, 16 March 2007 (edit)
Stepman (Talk | contribs)
m (Jira policy - minor speling and wording change)
← Previous diff
Revision as of 06:48, 16 March 2007 (edit) (undo)
Stepman (Talk | contribs)
m (Developer guidlines moved to Developer guidelines: spelling)
Next diff →

Revision as of 06:48, 16 March 2007


Code policy

  • Every function must be documented using XML Comments. The documentation should contain:
    • Input parameters, including acceptable value ranges if non-obvious
    • Output values, if any
    • Exceptions thrown, if any
    • Description of what the function does, including side effects ("also increments current frame number by one")
    • Name of original author (jira username and/or email address)

SVN policy

Applying for SVN commit access

  • If you only intend to make a few commits you should post your code on the forums and ask for someone to commit it for you.
  • If you intend to be an active contributor contact with reasons why you need access, your coding experience, and preferably the first piece code you want to commit.

Notes on committing to SVN

  • Every commit must have one corresponding jira issue. This issue code must be the first item in your commit message, followed by a colon. For example, a typical commit message looks like this: WW-778: Improved rendering performance with hardware vertex buffers.
    • Do not bundle up several issue codes in one commit; make a separate commit for each issue. This allows better tracking of what actually changed in response to each issue.
  • Check that your commit does not break SVN, i.e. World Wind still builds. This is especially important if you also have other, uncommitted changes. If you repeatedly break SVN your commit privileges will be revoked.
    • If you add a new file, be sure to also commit the updated .csproj file for the particular sub-project, and any necessary .resx files.

Jira policy

  • If you see an unassigned issue you wish to take on you can freely assign it to yourself.
  • If you see an assigned issue you wish to take on or help with contact the current assignee or email Never assume an issue has been abandoned.
  • Issues with more votes should be priortised. If you have several issues assigned to you fix the ones with most votes first, or unassign those issues and let someone else fix them.
  • If you believe you have fixed an issue, select resolved, and ask for someone else to verify your fix, they should then select fixed or comment on your issue if there are still problems.
Personal tools