Developers

From $1
Table of contents

If you want to contribute on the development of MonoDevelop, implement your own tools based on the platform, create new add-ins for the IDE, or just know more about the project, you'll find some useful information in this page. Here are some interesting links to start with:

  • Articles: A collection of articles written by the MonoDevelop community. You'll find technical documentation, tutorials and other useful information for learning about the MonoDevelop platform.
  • TODO: A list of features we would like MD to have. If you want to contribute, just pick one of them and notify through the mailing list that your are going to work on it.

Contribute

MonoDevelop is always looking for contributors to help with development. If you have some time and want to help, there are instructions below.

Reporting Bugs

Reporting bugs is a very easy way to help contribute to any project. MonoDevelop bugs are be filed at bugzilla.novell.com.

To report a bug, follow the steps below:

  1. Create a Bugzilla account.
  2. Ensure the bug you are reporting hasn't already been fixed. Install the latest version of MonoDevelop using the "Current Development" instructions on the download page.
  3. Review the open MonoDevelop bugs and make sure that your bug hasn't been submitted already.
  4. If it hasn't been submitted, submit a new MonoDevelop bug.

Error traces gathered by running MD from a terminal are often helpful in tracking down a bug. For more information read the article on logging.

Submitting Patches

If you submit a patch, it's always best to create the patch against the current snapshot version of MonoDevelop. To do it:

  1. Check out the source code from the repository (see Download).
  2. Make the changes you want to make.
  3. Write a ChangeLog entry for every change. There is a ChangeLog file at every assembly directory (that is, every subdirectory below Core/src and Extras).
  4. Run 'svn diff > change.patch' at the directory of the assembly you changed (see here for an example of patch).
  5. Send the change.path file.

If you cannot use this, then make sure you have the source for the latest release, and do the following:

  1. Copy the file before you edit it.
  2. Make the changes you want to make and save the file.
  3. On the command line type diff -u oldfile.cs newfile.cs > vardec.patch. The name of the patch should be something quick which describes what you fixed.

If the patch fixes a bug, it's better to create a bug in bugzilla.novell.com and attach the patch to the bug. If you're patching against a pre-existing bug, just attach to the bug. Otherwise you can just send the patch to the MonoDevelop Developer Mailing List or the MonoDevelop Mailing List.

The commit archive can be found here.

If you have SVN commit rights, it is preferable to use the svnci script which is located in the top monodevelop directory. This script will ensure that the commit message for each subdirectory is the same as the change made to the according ChangeLog.

Commit Rules

There are a few rules to follow when committing code:

  1. Always add a ChangeLog entry with a meaningful explanation. Every assembly has its own ChangeLog file.
  2. Enter a meaningful explanation in the commit log message as well. That's usually the same message you write in the ChangeLog.
  3. When entering a message describing a change, take into account that the goal is to explain why the change was done, rather than what was changed. For example, the message "Added property X" is in general useless since it is obvious looking at the patch.
  4. Don't do commits which involve more than one assembly. Do one commit per assembly. As an exception, it is OK to commit a change involving several assemblies if the change done is the same for all files (for example, a global class rename, or tracking a change in the API).
  5. Don't do reformatting commits, unless you're the original author of the code.
  6. Never remove copyright notices from the code.
  7. Never remove licensing info from code.
  8. Never commit code you didn't write yourself or code that doesn't have a suitable license.

Coding Guidelines

New code written for MonoDevelop should follow the generic Mono Coding Guidelines.

with the following exceptions:

  • it is allowed to use camel case for field names.
  • code must be indented using tabs, not spaces

You should also follow our Human Interface Guidelines when designing windows and dialogs.

A Note on Licensing

All new code must be licensed under either a MIT X11.

Code and libraries licensed under version 2 of the LGPL license are acceptable under extraordinary circumstances.

Code licensed under the GPL cannot be accepted.

Although addins that do not follow these rules cannot be accepted into the MonoDevelop source repository, they can be hosted elsewhere. However, this generally means that they are much less likely to be maintained and distributed.

Working on the Website

We are always looking for help on developing the Monodevelop web site. If you're interested, please contact lluis at ximian dot com. Currently, we're are looking for the following:

  • Tutorials
  • Screenshots
  • Content writers

Any contributions you may have though would be appreciated. The list above is in no way all inclusive.

Tag page

Files (0)

 
You must login to post a comment.
Page last modified 22:56, 30 Nov 2009 by M.j.hutchinson