11# release
22
3- Builds & deploys a framework release.
3+ Builds the branches needed for a framework release.
44
55This tool is meant to help automate the process of
66launching a new release, by creating the release
7- distribution files, tagging everything properly,
8- and getting the repo branches in order.
7+ distribution files, ( tagging everything properly) ,
8+ and getting/keeping the repo branches in order.
99
1010## Audience
1111
@@ -22,24 +22,29 @@ There might be other feature branches, but they are not relevant to this process
2222
2323Once "develop" is ready for a new release, the general workflow is to
2424
25- - create a release branch from develop
25+ - create a " release" branch from develop
2626- update version dependencies or constants
2727- generate version(s) of the user guide
2828- move or ignore stuff, distinguishing release from development
2929- test that all is as it should be
30- - tag and merge the release branch into "master"
31- - merge "master" into "develop"
30+ - merge the release branch into "master"
31+ - ** manually ** create the release & tag on github, based on master
3232- put everything back where it should be for development
33- - remove the release branch
33+ - merge the post-release branch into "master"
34+ - merge the post-release branch into "develop"
35+ - ** manually** delete the release branches in the repo
36+ - ** manually** post a sticky announcement thread on the forum
37+ - ** manually** tweet the release announcement
3438
3539Visually:
3640
37- develop -> release -> master -> develop
41+ develop -> release -> master
42+ post-release -> master
43+ post->release -> develop
3844
39- Finally, there are a couple of manual tasks:
40-
41- - post a sticky announcement thread on the forum
42- - tweet the release announcement
45+ The ` release ` bash script does the first six workflow steps,
46+ and the ` post-release ` script does the other three between
47+ the manual steps.
4348
4449## Assumptions
4550
@@ -61,11 +66,10 @@ as part of a bug fix minor release.
6166
6267Inside a shell prompt, in the project root:
6368
64- `admin/release [test|deploy] version [qualifier]`
69+ `admin/release version [qualifier]`
6570
66- If the "deploy" action is not specified, the script execution is considered
67- a trial run, and nothing is pushed to the repo.
68- Whether or not deployed, the results are left inside
71+ Nothing is pushed to the repo. at this point -
72+ the results are left inside
6973the release branch in your local clone.
7074
7175The "version" should follow semantic versioning, e.g. ` 4.0.6 ` , and the
@@ -75,7 +79,16 @@ The "qualifier" argument is a suffix to add to the version
7579for a pre-release, e.g. ` beta.2 ` or ` rc.41 ` .
7680
7781Examples:
78- - ` admin/release test 4.0.0 alpha.1 ` would prepare the "4.0.0-alpha.1" pre-release PR
82+ - ` admin/release 4.0.0 alpha.1 ` would prepare the "4.0.0-alpha.1" pre-release PR
7983- ` admin/release 4.0.0 ` would prepare the "4.0.0" release PR
8084- ` admin/release peanut butter banana ` would complain and tell you to read these directions
8185
86+ Complete the next few steps of the release manually:
87+ - merge the release branch to "master"
88+ - push that to the main repo
89+ - on github.com, create an appropriate release (or pre-release)
90+
91+ Once the release branch has been vetted, and you have
92+ completed the manual steps, clean up with:
93+
94+ `admin/post_release`
0 commit comments