$wgGroupPermissions['user']['read'] = true; $wgGroupPermissions['*']['read'] = true; Core developper guidelines - Forge Wiki
SCM

Core developper guidelines

From Forge Wiki

Jump to: navigation, search

This is an (ongoing) list of things to remember before doing any change in CamiTK core and open-source tree.

This is an (ongoing) list of things to remember before doing any change in CamiTK core and open-source tree.

Contents

Do not modify camitk main trunk directly

If you want to add a new feature to CamiTK, please use the public incubator. By using the incubator you can start working with the CamiTK developer community. Moreover:

  • you get a functional versioning system (git) for CamiTK and the incubator (your commit are visible to anyone),
  • your code is included in the CamiTK automatic continuous integration,
  • you can directly get user feedbacks (anyone checking out the incubator get your latest development).

And... therefore this comes with some collective responsibilities:

  • your CEP top-level CMakeLists.txt should include enough contact and information about you and the objectives of your CEP,
  • you need to respect CamiTK coding convention,
  • you need to respect some rules about your commits (see below),
  • and as anyone updating the incubator, will have the new version of your code, if your code fail to compile, then you might get complaints!

If your feature cannot be developed separately from the sdk or the imaging and modeling CEP, then please contact the CamiTK team (core developers and maintainers) by email

When you feel that your feature is ready to be included in the main/supported trunk of CamiTK and be added to the next CamiTK release, then please contact the team to arrange timing and transfer details.

Plan and communicate

Tell the CamiTK team (core developers and maintainers) what you are planning to do to make sure it does not break any unformal or unwritten rule. Discussion is the best way to share your idea and improve CamiTK. You need to insert your idea in the main roadmap, so that it does not break the stability of the core, which is essential for all the developers.

Ensure backward compatiblity

Here you will find information of good guidelines to follow in order to assure the backword compatibililty of CamiTK of the next version with the older one.

  • Each C++ function should exist in the next version. Do not remove one.
  • Do not change the signature of methods.

Commit messages

To ensure a proper visibility/reading of what was done, start each line of your commit message one of the following commit keyword:

  • UPDATED when the commit update something that is not linked with any feature or bug (registered or not).
  • FIXED when the commit fix a problem that was not registered
  • BUG <ID> when the commit fix a problem that was registered in the bug tracking system (local, debian, launchpad...). Do not forget to change the bug status to CLOSE using the message "FIXED IN <revision number>".
  • NEW when the commit add a new feature that was not planned as a story in the scrum/sprint plan
  • FEATURE <ID> when the commit add a new feature that was planned as a story in the scrum/sprint plan. <ID> is the corresponding story id on icescrum or bug feature ID. If your feature doesn't come from a story, use a meaningful labelling text instead of ID.
  • HOTFIX <hotfix revision number> With a message that explain in what the hotfix correct the release (revision number mean : 4.0.1 where 1 is the hotfix number)
  • RELEASE <major or minor revision number> With a message that explain what are the main new featuresof this new release
  • MERGE <nameOfBranchToMergeFrom> TO <nameOfBranchToMergeTo> (ex : MERGE feature#75 TO develop). This is the default message, please leave as is.

Note: no semicolon please, just a space after each keyword.

Powered By FusionForge