...
When you clone from this repository, by default you'll getthe master branch, the latest, most recent version of the code base. This branch is under active development and ultimately will become the next major release of IGB. If you plan to develop IGB and would like your changes to be incorporated into the main repository and ultimately packaged for release to users, then you should issue pull requests to the master branch only.
To develop IGB, we use the Forking Workflow described in https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow
IGB branches and tags
IGB repository branches include:
- Master branch - code under active development; developers issue pull requests to the master branch only
- releaseCandidate branch - code to be packaged for release to users on BioViz.org; do not issue pull requests to this branch.
When we package IGB for release on the BioViz.org Web site, we create a new tag. If you need to view the source code for older versions of IGB corresponding to specific versions released to users, check out the corresponding tag. If you are developing an IGB App and want to write an App that is compatible with the currently released version of IGB, then check out the corresponding tag.
IGB versioning - major and minor releases
IGB version names use uses semantic versioning, described in Semantic Versioning 2.0.
...
In IGB, N is the major release number, M is the minor release number, and P is the micro or "bug fix" release number. (Bug fix releases are also called patches.)
All new minor release and bug fix releases of IGB support all API methods available supported in earlier releases sharing versions with the same major release number. New releases that increment the minor or micro numbers may contain changes to the API which are backwards compatible , but these will maintain backwards-compatibility with all prior versions from the same major release. They also may contain new interfaces not present in the earlier versions. A new This means that new minor or bug fix release should always be compatible with IBG Apps releases can run any IGB App built against earlier versions from the same major release.
New major releases of IGB will contain so-called "contract breaking" changes to the IGB API. This means that a new release that increments the major number (e.g., releasing IGB N.0.0) may include changes to the API methods that affect IGB Apps built using the previous major release.
To ensure that your users can run your App when a new major version is released, you should re-build your App using the latest IGB platform and release it in the usual way. We recommend you release versions of your App that are compatible with all major releases above IGB 8.0.0 to ensure that the greatest number of users can run your App. However, if you are unable to release an update to your App, users will always be able to run it using older versions of IGB, which they can get from our files download page at Sourceforge.
Before making a major release, the IGB core development team contacts everyone we know of who is developing IGB Apps to alert them to upcoming changes in the API.
| Info |
|---|
| If you're developing the core IGB code base, you should make changes to the master branch. For details, see Developing IGB. |
IGB release cycle - road map for 2016
...
Development of IGB versions being prepared for release to users will occur on the releaseCandidate branch, and we will tag each released version using the convention igb-M.N.P.
...
.
...
IGB code base
The IGB repository is organized into sub-projects, including:
...
QuickLoad testing
The following git repository contains broken QuickLoad sites that are helpful for testing within IGB.
...