Skip to content

Desktop Client Github Workflow

Christian Kamm edited this page Jul 17, 2019 · 3 revisions

This article will explain the git workflow and branching model we use to develop the ownCloud Desktop Client.

Active branches

  • master: active development branch
  • 2.6: bugfix branch (will become 2.6.0)
  • 2.5: bugfix branch (will become 2.5.5)

Branch explanation

Branch names:

  • master

    The main "active development branch"

  • minor release branch (1.8, 2.6, ...)

    Can be a "active development branch" or a "bugfix branch". Usually created with the first beta.

  • patch release branch (2.5.4, 1.8.2, ...)

    Used by release manager in preparation for a release. Deleted once signed tag was created.

  • other branches

There are two kinds of branches:

  • Active development branches

    This is where new features and enhancements are developed. All changes that are not bugfixes should target these branches.

    Usually only master is in this category. Sometimes a minor release branch is created early and is also an active development branch.

  • Bugfix branches

    These should receive only important or low-risk bugfixes.

Merges

Upwards merges are done occasionally. That means if 2.5 and 2.6 are active bugfix branches then 2.5 will be merged into 2.6 and 2.6 will be merged into master.

The reason that we're not cherry-picking fixes from master into release branches is that some automated tooling (transifex) needs to target the release branch and will add commits there.

Releases

When we are heading towards releases, a minor release branch is created from master. That happens usually with the release of the first beta and also means a harder feature freeze (the branch becomes a bugfix branch).

The patch releases are tags in the release branch. Git tags are created for every release (also betas) and should be used to specify the version to build in Jenkins.

Reviews

Use the Github pull request mechanism.