|
1 | | -# How to make a release |
| 1 | +# Release |
2 | 2 |
|
3 | 3 | ## On a fork |
4 | 4 |
|
5 | | -Initiate a Release Pull Request (PR). Ensure that the release branch includes the version in its name, as this will be utilized as the `future_version` for the GitHub changelog generator. |
6 | | - |
7 | | -See Rakefile |
8 | | - |
9 | | -```ruby |
10 | | - config.future_release = `git rev-parse --abbrev-ref HEAD`.strip.split('-', 2).last |
11 | | -``` |
12 | | - |
13 | | -Do the following: |
| 5 | +Please follow these instructions carefully. |
| 6 | +Ensure that you name the branch precisely as `release-vX.Y.Z` |
| 7 | +since this nomenclature is crucial for obtaining the `future_version` in the changelog. |
| 8 | +Your attention to this specific branch naming convention is essential for accurate version tracking in the changelog. |
14 | 9 |
|
15 | 10 | ```shell |
16 | 11 | export RELEASE_VERSION="X.Y.Z" |
17 | 12 | git switch main |
18 | 13 | git pull -r |
19 | 14 | git switch -c release-v$RELEASE_VERSION |
20 | | - |
21 | 15 | bundle config set --local path vendor/bundle |
22 | | -bundle config set --local with 'release' |
23 | 16 | bundle install |
24 | | - |
25 | 17 | CHANGELOG_GITHUB_TOKEN="token_MC_tokenface" bundle exec rake changelog |
26 | | - |
27 | 18 | git commit -am "Release v${RELEASE_VERSION}" |
28 | 19 | git push origin release-v$RELEASE_VERSION |
29 | 20 | ``` |
30 | 21 |
|
| 22 | +Then open a PR, discuss and merge. |
| 23 | + |
31 | 24 | ## After the merge, as a maintainer on upstream |
32 | 25 |
|
33 | 26 | ```shell |
34 | 27 | git switch main |
35 | 28 | git pull -r |
36 | | -git tag v$RELEASE_VERSION -m "v$RELEASE_VERSION" |
| 29 | +git tag v$RELEASE_VERSION |
37 | 30 | git push --tags |
38 | 31 | ``` |
| 32 | + |
| 33 | +## Tags |
| 34 | + |
| 35 | +Each puppetserver and puppetdb is accompanied by a build_versions.json file |
| 36 | +containing information about puppet releases and versions built when a tag is pushed or a change is made to the main branch. |
| 37 | + |
| 38 | +To enhance clarity and organization, we are transitioning from our previous tagging approach |
| 39 | +and will now distinguish the container tag from the puppet version. |
| 40 | +The new tags will follow the format vX.Y.Z. The CI build process operates within a matrix, |
| 41 | +leveraging the data from the JSON file to construct the specified versions. |
| 42 | +As a result, two Docker tags are currently generated: 7.13.0-vX.Y.Z corresponds to |
| 43 | +the Puppet Release 7.13.0 build with container version X.Y.Z, while 8.10.0-vX.Y.Z aligns |
| 44 | +with Release 8.10.0. These tags offer a more streamlined and informative representation of our build versions. |
| 45 | + |
| 46 | +The container tags like `7.13.0-main` and `8.10.0-main` are built automatically |
| 47 | +whenever changes are merged into the Git main branch. |
| 48 | +It's important to note that these tags are designated as development tags |
| 49 | +and might be subject to breakage, so exercise caution when using them. |
0 commit comments