# Guide for Developers

## Introduction
These are some guidelines that developers should be using when working on the SuperPuTTY application as developers

## Compiling SuperPuTTY From Source Code

### Prerequisites:
#### Using Visual Studio
* Visual Studio 2010 or Newer
* Wix Toolset (Optional, if you want to create an installer) Download from http://wixtoolset.org/
* NUnit (Optional, to run unit tests) 
* Git Source Control Provider (Recommended, integrates Git inside of Visual Studio IDE)

Clone repository from GitHub https://github.com/jimradford/superputty
Open SuperPutty.sln with Visual Studio, Press the F6 Key to build solution

#### Using alternative development environments
In case your're using another dev environment, like e.g. SharpDevelop, you'll additionally need:
* ["Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1"](https://www.microsoft.com/en-us/download/details.aspx?id=3138)

## Patches

If you have made changes to the SuperPuTTY Application or fixed a bug please send a pull request with your changes. If you prefer you can submit a patch as a unified diff in the issue tracker. Patches should be made against the trunk (Master) branch in most cases.

## Commit access

We are happy to provide commit access to anyone who shows a willingness to further the development of SuperPuTTY and shows a history of submitting useful patches to the project.

## Source Tree Layout

**master** is where current development happens and can be unstable or unusable but should always compile.

**branches** is where experimental features are developed. Any developer with commit access should use a naming scheme to make clear what the branch is and who the developer is e.g. jradford-lua might indicate developer jradford is experimenting with integrating lua into the application.

**tags** is where stable releases are located.

## Version Numbering

We will do our best to follow the Semantic Versioning guidelines as outlined on this website http://semver.org/ for version numbering. API changes are also meant to convey backwards compatibility with configuration files.