Developer Guidelines

Functionality, Playability, and Stability

We believe that in order to build a stable platform, we need to maintain consistancy in the development process.  The following guidelines will help you, the new Unity developer, to approach the project with confidence.  Thanks for your efforts.

 

  • We do not commit untested builds.  If you have made changes to the code, you should do a test build to make sure that there are no compile errors before you commit the changeset to the repo.
  • We do not commit code that we do not understand.  By this we mean that if you are porting code in from another source, you should make every effort to understand the code.  Better understanding means that we are less likely to break something in another part of the codebase with our new change.
  • We do not port changes that we do not need.  You must be prepared to justify your change.
  • We do not replace entire sub-systems without the consensus of the development team.  We must make every effort to avoid disruptive change unless it will result in major improvement to functionality, playability, or stability.
  • We make attribution and note the source on all commits.  Let's give credit where credit is due.  See the attribution list below for project abbreviations.

 

Code Standards

Please see the Code Standards document.

 

Project Abbreviations for Attribution

When you check in a change that has been ported from another source, please try to be consistent in noting the source.  The preferred format is SOURCE-REV_OR_HASH: DESCRIPTION.  So a commit based on rev 1800 from TrinityCore would be abbreviated TC-1800: Description of the change.

Projects

  • MaNGOS - MA
  • MaNGOS One - MO
  • TrinityCore - TC
  • OregonCore - OC
  • ArcEmu - AE
  • Hearthstone - HS
  • Ascent - AS
  • UDB - UD
  • YTDB - YT
  • ScriptDev2 - SD

Please let us know if we need to add to this list.

If you are porting code from one of these project's forums, just add the letter F (ex. TrinityCore forum would be TCF).

It is important to maintain proper version/revision information.  Please see the Release / Revision Number How-To for more information.

Thanks again for all your help!

Published on  October 26th, 2011