-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Revel Workflow
Here's the overall process followed in order to maintain the Revel project.
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)
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)
Automated scripts are maintained in revel/meta in the /release
folder which contains further documentation. The following is heavily based on that documentation.
This script will:
- create configuration file
Example ./configure.sh v0.18.0 go1.8
This script will:
- checkout all necessary code into
/tmp/release
- ensure that
develop
is up to date withmaster
(git merge master
) - create the
release/vx.x.x
branch fromdevelop
- update the
revel/revel
README.md
, andversion.go
- update the
revel/revel.github.io
version
- Echo commit messages to the changes.md
- manually tweak the changelogs; used for GitHub Release notes
- make any final changes before it goes to
master
- add any
README
updates
- execute
go test
onrevel
,cmd/revel
,config
,cron
- execute
revel test
onexamples/booking
andexamples/chat
- verify that everything passed (the script will fail if any exit non-zero)
- 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 all of the commits, branches, tags
- makes the release LIVE
- Confirm submitted issue/pull request is truly a critical issue
- Create patch branch for next patch version e.g.
patch-0.9.1
- Commit one or more fixes for the patch release
- Test for regression issues and working solutions
- Release patch
- Draft release
- Merge to
master
- Tag patch version
- Delete patch branch
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