Skip to content

Revel Workflow

Jump to bottom
Brenden Soares edited this page Apr 12, 2022 · 21 revisions

Revel Workflow

Here's the overall process followed in order to maintain the Revel project.

Reviewing Pull Requests

A valid PR will:

  • target develop branch
  • provide needed details to verify that real value is being added
  • for bugs, steps to reproduce are required
  • for enhancements, an RFC is often required for significant changes
  • be properly labelled by a team member (see labels in above list)

Incorrect Branch Targeted by PR

If the PR is addressing a bug, make sure to set clear expectations on what we need in order to accept the PR:

After that, please provide steps to reproduce the issue so we can 
ensure the problem you are attempting to solve is working as expected.
A new unit test is always welcome

Always show gratitude for their effort

Thank you!

Finally:

  • set the PR's milestone to Backlog (if the contributor never corrects the issue, we may want to manually retarget the PR ourselves in order to improve Revel)

Releasing

Major/Minor Releases

Automated scripts are maintained in revel/meta in the /release folder which contains further documentation. The following is heavily based on that documentation.

./configure.sh <version> <min golang version>

This script will:

  • create configuration file

Example ./configure.sh v0.18.0 go1.8

./prepare.sh

This script will:

  • checkout all necessary code into /tmp/release
  • ensure that develop is up to date with master (git merge master)
  • create the release/vx.x.x branch from develop
  • update the revel/revel README.md, and version.go
  • update the revel/revel.github.io version

./changelog.sh > changes.md

  • Echo commit messages to the changes.md
  • manually tweak the changelogs; used for GitHub Release notes

Manual Edits

  • make any final changes before it goes to master
  • add any README updates

./test.sh

  • execute go test on revel, cmd/revel, config, cron
  • execute revel test on examples/booking and examples/chat
  • verify that everything passed (the script will fail if any exit non-zero)

./release.sh <next version>

  • commit changes on revel/revel, revel/revel.github.io
  • create release tag (on all repos)
  • (TODO) add changelog notes to releases page (can we automate?)
  • merge release branch to master
  • merge master branch to develop
  • update version in develop to next version
    • release: v0.15.0
    • next version: v0.16.0-dev
  • commit new version to develop

./push.sh

  • push all of the commits, branches, tags
  • makes the release LIVE

Patch Releases

  1. Confirm submitted issue/pull request is truly a critical issue
  2. Create patch branch for next patch version e.g. patch-0.9.1
  3. Commit one or more fixes for the patch release
  4. Test for regression issues and working solutions
  5. Release patch
  • Draft release
  • Merge to master
  • Tag patch version
  • Delete patch branch

Website Releases

We use feature branches and PRs to merge into master. There is no develop branch. Updating the website repo during a release is a manual process done to update latest release version and date. @shawncatz will write a dedicated script step in the meta repo to automate this soon.

Development

Resources

Community

Clone this wiki locally