Releasing off older stable branches
Apart from having releases cut from the default master branch, Jekyll Core may occasionally cut releases containing security patches and
critical bug-fixes for older versions under maintenance. Such releases are cut from specially named branches, following the pattern
[x].[y]-stable where [x] denotes semver-major-version and [y], the semver-minor-version. For example, the branch 3.9-stable refers to
commits released as part of jekyll-3.9.x series.
Co-ordinating a release off a *-stable branch is complicated mainly because the default branch has to inevitably reflect the release as well.
Requirements
- The maintainer has to have write-access to both the concerned
*-stableandmasterbranches. - The maintainer needs to complete the task using their local CLI program instead of dispatching via GitHub Web UI.
- The maintainer is abreast with the workflow to release off
master. The procedure documented in the following section is an abridged adaptation of the workflow formaster. - A release post has been drafted and is awaiting publish to
mastervia an approved pull request. - Stable internet connection.
Trigger release workflow
- Ensure that you’ve checked out the concerned
*-stablebranch and is up-to-date with its counterpart atjekyll/jekyllat GitHub. - Bump the
VERSIONstring inlib/jekyll/version.rb. - Update the History document as documented here.
(IMPORTANT: Do not runrake site:generateon the stable branch though). - Copy the entire History section pertaining to current release and paste into a new tab / window of your text-editor. We will use this temporary snippet at a future stage.
- Commit changes to the version-file and History document with commit message
Release :gem: v[CURRENT_VERSION]. - Push commit to upstream remote
jekyll/jekyllat GitHub.
Publish release post
- Ensure the
Release Gemworkflow has completed successfully. - Merge release-post pull request to
master.
Update default branch to reflect release off the stable branch
- Locally, check out
masterand ensure it is up-to-date with its remote counterpart atjekyll/jekyllat GitHub. - Update History document using the snippet in the temporary tab / window created earlier. The various sections in the History document are
primarily in reverse chronological order and secondarily scoped to the semver-major-version. For example, a release section for
v3.9.2will be listed above the section forv3.9.1but under release sections for v4.x. The snippet stashed earlier has to be injected into the correct location manually. - Optionally, update
VERSIONstring inlib/jekyll/version.rb. (If existing version is lesser than latest version). - Now run
rake site:generateto update various meta files:- docs/_config.yml
- docs/_docs/history.md
- docs/latest_version.txt
- Commit changes to various meta files with commit message
Release :gem: v[CURRENT_VERSION]. - Push commit to upstream remote.
Publish GitHub Release
Unlike releases cut off the master branch, our JekyllBot does not automatically create and publish a GitHub Release for tags created from
non-default branches. Therefore, the maintainer has to manually create and publish the concerned GitHub Release.
- Choose the newly pushed tag.
- Title is same as the name of the selected tag.
- The release snippet stashed previously forms the body.
- Delete the snippet’s title (
## x.y.z / YYYY-MM-DD) from the release body. - Publish.
Note: The GitHub Release may optionally be drafted prior to updating the default branch and then published immediately after pushing the update commit to the default branch to streamline the procedure.