|
30 | 30 | * Tag the appropriate branch with the updated version (e.g. v1.34.0-4). The tag will kick off a DO pipeline with integration tests. |
31 | 31 | * If the DO pipeline is successful, that pipeline will upload the build artifacts to Artifactory and send the release email to the `f5-declarative-onboarding` distribution list. |
32 | 32 |
|
| 33 | +## Process for LTS release |
| 34 | +* Using the GitLab GUI, create a branch from the release branch that we are declaring LTS. Bump the patch version by 1. For example, if we are declaring 1.36.0 to be LTS, then create a 1.36.1 branch from 1.36.0. |
| 35 | +* On your local machine, fetch and checkout the LTS branch. |
| 36 | +* Create a new local branch from the LTS branch (e.g. "prepare-1.36.1-release"). |
| 37 | +* Update the patch version in `package.json` and `package-lock.json`. The release number of the new version should start at 0 (e.g. 1.36.0-4 would become 1.36.1-0). |
| 38 | +* Add a new CHANGELOG section that looks like |
| 39 | + ``` |
| 40 | + ## 1.36.1 |
| 41 | + ### Added |
| 42 | +
|
| 43 | + ### Fixed |
| 44 | +
|
| 45 | + ### Changed |
| 46 | + - Promoted to LTS |
| 47 | +
|
| 48 | + ### Removed |
| 49 | + ``` |
| 50 | +* Create an MR for these changes. Important: Remember to set the branch you are merging into to the LTS branch. |
| 51 | +* Go to the atg-build project in GitLab |
| 52 | + * Edit the DO schedule to set the `gitBranch` variable to the LTS branch. |
| 53 | + * Run the DO schedule. |
| 54 | + * After the build completes, edit the DO schedule to set the `gitBranch` variable back to develop. |
| 55 | +* Using the GUI create a tag off the LTS branch (e.g. 1.36.1) |
| 56 | + * In the GUI go to `Repository -> Tags -> New tag`. |
| 57 | + * The name of the tag should be the LTS version with a 'v' at the front (e.g. v1.36.1). |
| 58 | + * Update the `createFrom` to point at the LTS branch. |
| 59 | + * Set the message to: `LTS release v<LTS version>` (e.g. "LTS release v1.36.1") |
| 60 | +* Merge the release branch (without updating the package version) into develop and create an MR for this. |
| 61 | +* Merge the release branch (without updating the package version) into master and create an MR for this. |
| 62 | +
|
33 | 63 | ## Process for release |
34 | 64 | ### Begin process release at the very beginning of the first sprint of a new release, by performing the following actions: |
35 | 65 | * Follow the instructions for setting up a release candidate (see [Process for release candidates](#Process-for-release-candidates)). |
|
0 commit comments