1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
|
= Releases
== General notes
* Avoid tagging commits in the `main` branch.
* Release branches should have annotated tags and a CHANGELOG.md.
* The steps below detail creation of a brand new 1.0.0 release.
Some steps would be omitted for minor releases.
== Creating an initial release
=== Update documentation
Update references to version numbers in relevant documentation to the new
version you intend to release.
[source,console]
----
git checkout main
vim docs/installation.adoc
git add docs/installation.adoc
git commit
git push
----
=== Create branch
Release branches have names of the form `release/N.x`, where N is the major
version (and `x` is a literal -- not a placeholder).
[source,console]
----
git checkout -b release/1.x main
----
[[update-changelog-and-version]]
=== Update CHANGELOG and version
[source,console]
----
vim CHANGELOG.md
# Add/update CHANGELOG entry for the new version
git add CHANGELOG.md
echo 1.0.0 > version.txt
git add -f version.txt
git commit
----
=== Create tag
An initial release would be tagged as follows:
[source,console]
----
git tag -a v1.0.0 -m ''
----
=== Push branch and tag
[source,console]
----
# push the branch
git push origin release/1.x
# push the tag
git push origin v1.0.0
----
=== Edit tagged release description on GitHub
. Navigate to the link:#https://github.com/rnpgp/rnp/releases[Releases] page;
. Edit the tag that was just pushed;
. Fill the tag's description with data from the corresponding `CHANGELOG`
entries of the same tag version;
. Publish the release.
== Creating a new release
Maintaining a release branch involves cherry-picking hotfixes and
similar commits from the `main` branch, while following the rules for
Semantic Versioning.
The steps below will show the release of version 1.0.1.
=== Add desired changes
Cherry-pick the appropriate commits into the appropriate `release/N.x` branch.
To see what commits are in `main` that are not in the release branch, you
can observe the lines starting with `+` in:
[source,console]
----
git cherry -v release/1.x main
----
It is often useful to pick a range of commits. For example:
[source,console]
----
git checkout release/0.x
git cherry-pick a57b36f^..e23352c
----
If there are merge commits in this range, this will not work.
Instead, try:
[source,console]
----
git checkout release/0.x
git cherry release/0.x main | grep '^+ ' | cut -c 3-9 | \
while read commit; do git cherry-pick $commit; done
----
From here, you can follow the steps for an initial release,
starting with <<update-changelog-and-version>>.
|
