diff --git a/docs/en/qgc-dev-guide/getting_started/index.md b/docs/en/qgc-dev-guide/getting_started/index.md index 7dcaa2e..a6e2f3d 100644 --- a/docs/en/qgc-dev-guide/getting_started/index.md +++ b/docs/en/qgc-dev-guide/getting_started/index.md @@ -2,7 +2,7 @@ qt_version: 5.15.2 --- -# Getting Started +# Getting Started with Source and Builds This topic explains how to get the _QGroundControl_ source code and build it either natively or within a _Vagrant_ environment. It also provides information about optional or OS specific functionality. diff --git a/docs/zh/qgc-dev-guide/ReleaseBranchingProcess.md b/docs/zh/qgc-dev-guide/ReleaseBranchingProcess.md deleted file mode 100644 index 9823fed..0000000 --- a/docs/zh/qgc-dev-guide/ReleaseBranchingProcess.md +++ /dev/null @@ -1,73 +0,0 @@ -# QGroundControl Release/Branching process - -## Semantic Versioning - -QGC uses semantic versioning for the version numbers associated with its releases. Semantic versioning is a 3-component number in the format of `vX.Y.Z`, where: - -- `X` is the major version. -- `Y` is the minor version. -- `Z` is the patch version. - -## Stable Builds - -The current stable build is the highest quality build available for QGC. [Patch releases](#patch_releases) of the stable build are regularly made to fix important issues. - -Stable builds are built from a separate branch that is named with the format: `Stable_VX.Y` (note, there is no patch number!) The branch has one or more git tags for each patch release (with the format `vX.Y.Z`), indicating the point in the repo source code that the associated patch release was created from. - -### Patch Releases {#patch_releases} - -A patch release contains fixes to the stable release that are important enough to _require_ an update, and are safe enough that the stable release continues to maintain high quality. - -Patch releases increment the patch version number only. - -### Patch - Development Stage - -Approved fixes to the stable release are commited to the current stable branch. These fixes continue to queue up in the stable branch until a patch release is made (see next step). - -Commits/changes to the stable branch must also be brought over to the master branch (either through cherry pick or separate pulls). - -### Patch - Release Stage - -At the point where the decision is made to do a patch release, the release binaries are created and a new _tag_ is added to the stable branch (with the same patch release number) indicating the associated source code. - -::: info -New branches are not created for patch releases - only for major and minor releases. -::: - -## Daily Builds - -### Development Stage - -Daily builds are built from the `master` branch, and this is where all new major feature development happens. The state of master represents either the next minor point release, or a new major version release (depending on the level of change). - -There are no git tags associated with a released daily builds. The released daily build will always match repo HEAD. - -### Release Stage - -When the decision is made to release a new major/minor version the master branch tends to go through an intial lockdown mode. This is where only important fixes for the release are accepted as pull requests. - -::: info -During the lockdown phase, new features are not allowed in master. -::: - -Once the level of fixes associated with the release slows down to a low level, a new stable branch is created (at this point the `master` branch can move forward again as the latest and greatest). - -Fixes continue in the stable branch until it is deemed ready to release (ideally after a short time)! At that point the new stable branch is tagged with the new version tag and the first stable release is made. - -## Custom Builds - -A proposed strategy for branching on custom builds can be found [here](custom_build/release_branching_process.md). - -## Process to create a new Stable - -### Major/Minor Version - -1. Create a branch from master named `Stable_VX.Y` where `X` is the major version number and `Y` is the minor version number. -1. Create a tag on the HEAD of master name `dX.Y` where the minor version is one greater than the new Stable. For example if you are create a new Stable 4.2 version then the tag would be 'd4.3'. This tag is used to create the version numbers for Android daily builds. Example: `git tag -a d4.3.0 -m "QGroundControl Daily Android Version Base"`. -1. Create an annotated tag on the newly created Stable branch named `vX.Y.0` with the correct major/minor version number. Example: `git tag -a v4.2.0 -m "QGroundControl v4.2.0"`. Pushing this tag to the repo will start a build. -1. Once the build completes verify the builds are pushed up to S3 correctly and sanity check that they at least boot correctly. Location on S3 will be `https://qgroundcontrol.s3.us-west-2.amazonaws.com/latest/...`. -1. Update the `https://qgroundcontrol.s3.us-west-2.amazonaws.com/builds/latest/QGC.version.txt` text file to the latest Stable version. This will notify uses there is a new Stable available the next time they launch QGC. - -### Patch Version - -Creating a new Patch Version is the same except you skip steps 1 and 2 and in step 3 you bump the patch version number up as needed.