|
1 | 1 | ## Release process |
2 | 2 |
|
3 | | -With every build, the build process on Travis updates files with an appropriate version number before deployment into the database. |
4 | | -This step is performed, to confirm that the update of versions works properly. |
| 3 | +To create a release follow the below steps |
5 | 4 |
|
6 | | -## To create a release |
7 | | - |
8 | | - - create release branch from development branch and make sure to name the release branch: `release/vX.Y.Z` |
9 | | - - update, commit and push at least one file change in the release branch, to kickoff a Travis build |
10 | | - - wait for th build to complete successfully |
11 | | - - merge the release branch to main and wait for main build to complete successfully (do not use Squash/rebase for merge operation) |
12 | | - - create a Github release from the main branch using [github releases page](https://github.com/utPLSQL/utPLSQL/releases) and populate release description using information found on the issues and pull requests since previous release. |
| 5 | +## Release preparation |
| 6 | + - Create a **draft** of Release from the `main` branch using [github releases page](https://github.com/utPLSQL/utPLSQL/releases) and populate release description using information found on the issues and pull requests **since previous release**. |
13 | 7 | To find issues closed after certain date use [advanced filters](https://help.github.com/articles/searching-issues-and-pull-requests/#search-by-open-or-closed-state). |
14 | 8 | Example: [`is:issue closed:>2018-07-22`](https://github.com/utPLSQL/utPLSQL/issues?utf8=%E2%9C%93&q=is%3Aissue+closed%3A%3E2018-07-22+) |
15 | | - - After A build was completed on a TAG (github release) was successful, merge main branch back into develop branch. |
| 9 | + |
| 10 | +## Performing a release |
| 11 | + - create the release branch from `develop` branch and make sure to name the release branch: `release/vX.Y.Z` |
| 12 | + - update, commit and push at least one file change in the release branch, to kick off a build on [GithubActions](https://github.com/utPLSQL/utPLSQL/actions) or kick-off a build manually for that branch after it was created on github. |
| 13 | + - wait for the build to complete successfully as it will update the version to be release number (without develop) |
| 14 | + - merge the release branch to `main` branch and wait for build on `main` branch to complete successfully (do not use Squash/rebase for merge operation) |
| 15 | + - Publish the release on the `main` branch and tag it with version number `vX.Y.Z` |
| 16 | + - Wait for the release build to finish successfully on Github Actions as this will upload release artifacts (`zip` and `tar.gz` files along with `md5`) |
| 17 | + - After A Release build was completed successfully, merge main branch back into develop branch. |
16 | 18 | - At this point, main branch and release tag should be at the same commit version and artifacts should be uploaded into Github release. |
17 | | - - After develop branch was built, update version number in `VERSION` file to represent next planned release version. |
| 19 | + - After develop branch was built, increase the version number in `VERSION` file to represent next planned release version. |
18 | 20 | - Clone `utplsql.githug.io` project and add a new announcement about next version being released in `_posts`. Use previous announcements as a template. Make sure to set date, time and post title properly. |
19 | 21 |
|
20 | 22 | The following will happen: |
21 | 23 | - build executed on branch `release/vX.Y.Z-[something]` updates files `sonar-project.properties`, `VERSION` with project version derived from the release branch name |
22 | | - - changes to those two files are committed and pushed back to release branch by Travis |
23 | | - - builds on main branch are **not getting executed** |
24 | | - - when a Github release is created, a new tag is added in on the repository and a tag build is executed |
25 | | - - the documentation for new release is published on `utplsql.github.io` and installation archives are added to the tag. |
| 24 | + - changes to those two files are committed and pushed back to release branch |
| 25 | + - when a Github release is published, a new tag is added in on the repository and a release build is executed |
| 26 | + - With Release build, the documentation for new release is published on `utplsql.github.io` and installation archives are added to the release. |
26 | 27 |
|
27 | | -Note: |
28 | | -The sources for release are provided in separate zip files delivered from the Travis build process. |
29 | | -The built zip files include HTML documentation generated from MD files. |
| 28 | +# Note: |
| 29 | +The utPLSQL installation files are uploaded by the release build process as release artifacts (separate `zip` and `tar.gz` files). |
| 30 | +The release artifacts include HTML documentation generated from MD files, sources and tests |
0 commit comments