-
Notifications
You must be signed in to change notification settings - Fork 126
Merging a Pull Request
Once a pull request has been merged, the following additional steps are required.
See Pageflow's versioning policy for details on what constitutes a breaking change or a manual update step.
-
If the pull request has been merged into
master
, assign a milestone corresponding to the next minor version that will be released. -
If the pull request contains a backport of a bug fix and has been merged into a stable branch (e.g.
stable-12-1
), assign a milestone corresponding to the next patch level version that will be released for the minor version series of the stable branch (e.g.v12.1.2
if 12.1.1 is the latest release patch level version in the 12.1 series).
Assigning the correct milestone ensures that pull requests can correctly be turned into changelog items.
Consider applying one of the following labels:
-
manual update step
Developers of host applications need to perform additional steps after upgrading to a Pageflow version containing the change. -
bug
The change fixes a bug and should be displayed with a "Bug fix:" prefix inside the changelog.
If the pull request requires a manual update step, make sure the pull request description contains clear instructions that can be incorporated into the changelog later on.
Assign a milestone corresponding to the next major version.
Assign the breaking change
label.
Make sure the pull request description contains detailed information about the introduced API change.
If lib/pageflow/version.rb
does not yet track the next major version, invoke the following task and update the master
branch:
$ bin/rake bump:major
$ git commit -m "Bump major version"
$ git push upstream master
Create a stable branch for the previous major version. Assuming last released version is 12.10.2
$ git branch v12-x-stable v12-10-stable
$ git push upstream v12-x-stable
The v12-x-stable
can be used to backport features in case there should ever be a 12.11.0 release.