Contributing?

That's fantastic. This library relies upon the contributions of time, effort, resources and finance from individuals and companies. Significant investment in such areas has got us to where we are today, but we always need more - Without help from people such as yourself, there would not be a DotNetOpenAuth library.

Starting out

First, check out the Developers Quickstart, then the coding guidelines.

GIT Source Control

We use GitHub to host the DotNetOpenAuth project. If you are new to GIT, we recommend you give this series of articles a read.

GitHub makes it very easy to fork projects so that you can make your own changes to a project and optionally get your changes incorporated back into the original project. If you want the source code so you can make changes to it, whether or not you are interested in contributing your changes back here, forking may be a good way to track what changes you make, and allow you convenient sharing of patches between the two projects.

Branch management

Whether you contribute directly to the main project or to a fork of the project, it is important to understand how branches are managed in this project. The masterbranch is where most feature work occurs. It is generally not a stable branch and should not be used in production. As the next major release approaches, we branch off of master with a name of the convention vx.y. At this point, only bug fixes get checked into this stabilization branch. Once the branch is stable enough for a release, we tag a commit with the full version number of that release.

A single vx.y branch may provide several releases. For example, the v2.5 branch has been tagged at versions v2.5.0.8281, v2.5.1.8313, etc. when sufficient bug fixes since the last release in a particular branch justifies another minor release.

Bug fixes should be checked into the earliest branch to which it applies. For example, if a bug is discovered that affects the v3.1, v3.2, and master branches, we check the bug fix into v3.1 only. Before a release (and periodically in between releases) we merge from earlier branches to later branches in order to roll up bug fixes to all later versions. This means that some bug fixes will only exist in v3.1 for several weeks, leaving the bug present in v3.2 and later in the meantime. This turns out to usually not be a big problem. If it is, we can just merge the v3.1 branch into the v3.2 branch, or do a git cherry-pick to get the bug fix into the other branch faster.

Getting the code

Command-Line Access

If you plan to make changes either for yourself or to contribute back, use this command to check out the code using Git:

git clone git://github.com/AArnott/dotnetopenid.git

Browser Access

If you only want a source code drop and do not plan on contributing changes back, you may also use your browser to visit the following URL:

Repo Url: http://github.com/AArnott/dotnetopenid/tree

From here you may download individual files or "snapshots" of anything you like. If you download a snapshot and you're using Windows, you'll need to extract the .tar.gz file. You can use WinZip for this, or read up on how to extract source from .tar.gz files using FOSS (but the FOSS-way is harder).

Getting Git

Download Git: Git is available on Windows and Linux. You can find out more about Git on Wikipedia.

• Crash Course on Git for SVN users

Google's SVN server for this project doesn't have the latest work on this library. But if you still prefer to use SVN to download an old version, it's still there.

Which branch should you use?

On the web page for our repository, at the bottom you'll see a section called "heads". These are our branches. "master" is where most of the active work goes, while the others are our stabilization branches that eventually turn into released versions. When a version is released an entry under the "tags" section is added.

If you're planning on using this library in a production web site, avoid using master, as we cannot guarantee its readiness for production web sites. For production use, you should download a tagged release, or at very least go for one of the stabilization branches.

Commit access

If you have been invited by a project coordinator to receive commit access to our official Git repository, here is what you need to know.

1. Generate an SSH public/private key pair. You can get directions for generating a public key for yourself from here: http://github.com/guides/providing-your-ssh-key#windowsxp
2. Register as a user at our Git host
3. Send us your new repo.or.cz username.
4. Read up on the Contribute page.
5. Definitely install Git and clone the repository.
6. Set up a remote to the git central repository with the push going to this address, where _username_ is replaced by your repo.or.cz username: git+ssh://_username_@repo.or.cz/srv/git/dotnetopenid.git