Revel Workflow

Brenden Soares edited this page May 12, 2017 · 16 revisions

Revel Workflow

We use GH Issues primarily for reporting & fixing bugs and discussing & implementing features. Releases are put together using waffle

Development

Github Labels

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

  1. Setup environment for develop for release
  • go get github.com/notzippy/repo-tool
  • mkdir ~/somewhere/working
  • cd ~/somewhere/working
  • repo-tool init -b develop -u git@github.com:revel/meta.git
  • export GOPATH=$PWD:$GOPATH
  • go test -v github.com/revel/revel
  • go build -o ./revel github.com/revel/cmd/revel
  1. Test develop branch in repo {revel, cmd, config, modules, cron}
  • ./revel test github.com/revel/examples/booking
  • Update release build date in revel/version.go
  • Manually test Samples and unit tests
  • Update README.md necessary thing for current release
  • Push develop branch and Confirm Travis CI build pass
  1. Merge and Create Release tag
  • Merge them to respective master branch in order (important)
    • { cron, modules, config, cmd, revel }
  • Tag master branch according to Semantic Versioning
    • Repo's {revel, cmd, config, modules, cron, samples, heroku-buildpack-go-revel}
  • Add Release notes to revel/revel repo, please refer previous release notes for guidance
    • Cover instructions to transition any breaking changes
  1. Update Revel Website revel.github.io
  • Update _data/version.yaml for release
  • Manual matches new release changes
  • Finally merge develop branch into master
  • Tag master branch according to Semantic Versioning
  1. Announce Release
  • Reddit /r/golang
  • Golang-nuts mailing list
  • Revel mailing list
  • Revel IRC (freenode#revel)

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.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.