Versions Compared

Old Version 4

changes.mady.by.user Aaron Cuevas

Saved on

compared with

New Version Current

changes.mady.by.user Aaron Cuevas

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Type "t" anywhere in the GitHub code pages to activate a search function. It works amazingly well! Probably better than anything on your desktop. (Hit space to get out once you're finished).
  • Git aliases are a great way to save time. A really handy one is `git config --global alias.s "status -s"`

GitHub branches

Since the GUI is in a state of continuous development, to be able to both provide a stable version of the GUI while improving and adding features, we've created three different working branches on github. Al pull requests must adhere to the policies of each one:

  • Development branch: This branch is where most of the development will be done in this branch so, as such, any pull request can be performed into this one.
  • Testing branch: Any time the development branch is in a seemly stable state, and specially before pulling or committing any big change, the contents of the development branch will be merged into the testing one. The only commits allowed for this branch are those that do not add any new features to the GUI, but improve or fix the existing ones.
  • Master branch:The aims of this branch are stability and compatibility. Both the core GUI and plugins contained in this branch are guaranteed to be compatible with the ones in the most recent numbered version, available in the binary releases. Only code that is allowed to be merged into this branch is, then, fixes to already present functionalities which do not alter the plugin API in any way. Every time a new numbered version is released, the code from the testing branch will be pulled here and new binaries will be created.

For maintaining code coherency, every time there is a change in the Master branch, its contents will be merged into both Testing and Development. The same way, if there are changes merged into Testing, this branch will also be merged into Development. This assures that all commits in Development are always ahead of Testing and all in Testing are always ahead of Master, but never at the inverse.

In the case of plugin development, we actively encourage developers to maintain their own repositories and publish them in the relevant wiki page.This way their plugins can be easily developed and distributed without having to adhere to our release cycles.