Difference between revisions of "Development"

Revision as of 15:43, 13 January 2014

To get the official links to Jalview's source, head over to www.jalview.org/development

Here you'll find notes and helpful info about various aspects of Jalview development.

Getting started with Jalview Development

Do register at issues.jalview.org

You need to have a login at http://issues.jalview.org to be able to contribute to jalview.org. Do it now. If you register, you can also make this wiki better!

Checkout Jalview from GIT

git clone https://source.jalview.org/git/jalview.git

You'll probably need to disable SSL certificate checking for this to work, and you'll need your username and password to access the repository. If you just want to check out the source and not commit, then use 'git clone http://source.jalview.org/git/jalview.git'

Take a look at the current release schedule for Jalview

The current release schedule lives at http://issues.jalview.org/browse/JAL#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel We are always working on at least one Jalview release, and there's always something being developed for a future version.

• The version in the master branch is the one available from the Download/Launch buttons on the website.
• Release_X_Y_Z_Branch is the latest code for version 'X.Y.Z' of Jalview. We started this convention with Jalview 2, and it will most likely continue into the jalview 3 series (though things are going to get complicated there!).
  • Release branches for the current and the next release should always be available
• develop includes code that will be incorporated into some future version of Jalview.
  • If you want your patch to appear anytime soon, DO NOT START WORKING ON THE DEVELOP BRANCH!

Committing to the Jalview's GIT repository

To ensure that your work gets incorporated into the main Jalview version as soon as possible, you should make sure that any patches or commits that you make to Jalview follow some simple guidelines:

Don't make your commit too large

Generally, your commit is too large if you can't come up with a short sentence explaining the where/what/why of the commit (in the context of the JAL-XXXX issue).

• If you have got lots of changes, then use an interactive commit tool to select specific hunks that relate to each other (e.g. applying i18n string extraction to a particular window, and then committing the updated GUI code and the new keys added to the Message bundle).

• • Eclipse isn't particularly good at this type of commit, so I'd recommend you try typing git gui if you have command line git installed, download Atlassian SourceTree (or if you have a Mac, try GitX, which is far simpler and about as good !), or try one of the many other graphical GIT clients out there.

Don't commit broken code or part of a patch

Commits should (wherever possible) not introduce compilation errors, and the compiled system should be more or less functional. If you have a series of interdependent commits, then it should be obvious from the commit message (one or more common JAL-xxxx ids, etc).

It is *extremely important* that you get into these habits, because otherwise, it takes us much longer to review your work, and it makes it much harder to identify any new bugs that might arise as a result of your commits..

of course, no one ever commits buggy code, but hibernating bugs are easy to wake ;)