-
Notifications
You must be signed in to change notification settings - Fork 102
RemoteTech Developer's Handbook
[work in progress]
We follow the Git flow branching model, also simply known as "Git Flow".
- See here for a cheat-sheet.
- See here for a set of scripts and tools.
- If you are lost with Git Flow, I suggest you use SmartGit (see the Tools section below).
Below is a list of tools that might come in handy:
- Visual Studio: an IDE from Microsoft, exist in a free (as in beer) version.
- Git: a version control system, used by Github (you might want to use Github Desktop)
- SmartGit: a graphical Git client (free for Non-commercial use), Git flow is integrated.
We try to follow the Framework Design Guidelines from Microsoft whenever possible.
See also the following documents:
- C# Coding Conventions (C# Programming Guide) from Microsoft.
- .net Naming Conventions and Programming Standards - Best Practices for a cheat sheet.
As RemoteTech is a plugin for KSP which itself use the Unity engine you should be wary when using – notably – foreach loops and LINQ statements.
There is a good literature on the subject:
- C# MEMORY AND PERFORMANCE TIPS FOR UNITY
- C# PERFORMANCE TIPS FOR UNITY, PART 2: STRUCTS AND ENUMS
- C# Memory Management for Unity Developers
- REDUCING MEMORY USAGE IN UNITY, C# AND .NET/MONO
Note: We don't try to push too hard on the above guidelines, they form a guide not an absolute rule.
When writing new code for RemoteTech, please follow the following steps:
Read the titles of open issues and pull requests, to see if somebody's already thought of your idea.
If the issue has somebody assigned (see the rightmost column of the page), it's already being taken care of. Otherwise, assign yourself and/or add a comment saying you'll do it.
Fork RemoteTech and do any code updates. Like most KSP plugins, RemoteTech's code is organized around a solution (.sln) file, which can be opened with any of several C# development tools. Third-party developers can ignore the build.remotetech.sh script; it is needed only to support automatic builds from the online repository.
What happens next depends on what the new code does.
New features must be created in a feature branch (with the prefix feature/).
First, ask for the feature that you'd want to be implemented in an issue. If you have a green light for the feature, a RemoteTech developer will create the requested branch and you can then fork the repository and work on this branch.
There are 3 possibilities:
- HotFix: a critical bug is discovered after a release version has been shipped
- Release Fix: the release branch is still open (RemoteTech is not shipped yet, but will be released soon)
- "Standard" Fix: A non criticial bug is found
Note: if you are lost, ask us. By default, consider using the develop branch.
If the bug is a real showstopper then it can be deemed as a hotfix: hotfixes arise from the necessity to act immediately upon an undesired state of a live production version. For RemoteTech this means that it has been already publicly released and a bug renders it unplayable.
Create a hotfix branch (with a hotfix/ prefix, for example hotfix/myhotfix) and make your commits on this branch. If you haven't a write access to the repository, ask us to make the branch for you: in case you haven't an answer form us in 24 hours, you can make your change against the develop branch.
Once ready please create a new pull request.
A release fix is a bug fix when the release branch (with a release/ prefix, like release/2.0.1 is still open (otherwise consider a hotfix or a standard fix).
In this case please create a new issue and make a full bug report and please also tell us you'll be working on the issue.
Once the fix is ready, create a new pull request.
A standard fix is when a bug fix applies to a bug that is not critical and the release branch is closed.
This type of bug fix can be either done in a feature branch (feature/ prefix) and in the develop branch.
Once the fix is ready, create a new pull request.
Once your code is ready, create a new pull request: one of the Remote Technologies Group members will merge the pull request; if you yourself are a member, please wait one week to give others a chance to give feedback.