Skip to content
Jérémie Bresson edited this page Jun 21, 2018 · 7 revisions

The OpenAPI Generator project works on multiple versions in parallel:

  • upcoming patch release
  • next minor release containing breaking changes with fallback
  • next major release containing breaking changes with no fallback

Branches

To support several versions, several branches are used:

openapi-generator_branches

Status in June 2018:

  • master branch is for upcoming patch releases (3.0.1, 3.0.2, 3.0.3, ...)
  • 3.1.x branch for the next minor release
  • 4.0.x branch for the next major release

Merge direction

To port changes from one branch to an other, the merge direction is always from the lowest version to the newer.

Example:

  • Merge master branch into 3.1.0 branch
  • Merge 3.1.0 branch into 4.0.0 branch

Those merge commits are done regularly by the core team.

Merge commit is kept in the history in order to facilitate merge conflict resolution.

Merging back on master

When we drop the support for 3.0.x, we'll merge 3.1.0 back into master.

How-to: create merge commit.

Be careful of the merge direction.

Example for master -> 3.1.x branch:

git fetch
git checkout origin/3.1.x -B 3.1.x
git merge origin/master

Review the merge commit. You can run some checks locally mvn clean verify, bin/utils/ensure-up-to-date...

git push

Solving conflicts during merge

TODO, add useful git command, inspired by the discussion in https://github.com/OpenAPITools/openapi-generator/issues/245

Necessary steps when a new working branch is created

  • Edit the if condition in the .travis.yml file to allow the working branches to do a mvn deploy of the artifacts
  • Set it as protected branch in the GitHub configs
  • Update readme (branch list, badges…)