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
|
# How to release a new blogc version
These are some rough steps required to produce a blogc release.
## Define version number
- Read repository logs:
```
$ git log v0.18.0 # replace with whatever latest release
```
- Follow this criteria:
- Only bug fixes: Bump micro version.
- Something new: Bump minor version, set micro to `0`.
- We have no plans to change major version so far. Keep it `0`.
## Prepare release
- Write blog post (repository is https://github.com/blogc/blogc.rgm.io/)
```
$ cp content/news/blogc-0.18.0.txt content/news/blogc-0.19.0.txt # replace versions
$ vim blogcfile # change LATEST_RELEASE, add new post file to the end of [posts]
$ vim content/news/blogc-0.19.0.txt # write the content, based on what changed. put some placeholder DATE
$ blogc-make runserver
```
- Copy manpage sources from main repository (https://github.com/blogc/blogc):
```
$ cp -r ../blogc/man/* man/
$ make -C man
```
ronn output is not idempotent. It may rewrite HTML for manpages that are unchanged. Make sure to discard these changes somehow with git.
- Write GitHub release draft. Content is similar to blog post. No need to include lots of links. Always append this to the end of text:
```
Please download the custom tarballs, not the files generated automatically by GitHub, they are garbage.
```
## Bump version
- Make sure that all the code is in place.
- Edit `blogc.spec.in`. Check if dependencies and packaging are still correct.
- If something needs update, do it. Then commit, push and wait for [CI](https://github.com/blogc/blogc/actions). After successful build, grab a `.src.rpm` from https://distfiles.rgm.io/blogc/LATEST/, upload to a test [Copr](https://copr.fedorainfracloud.org/), wait until it builds and follow also next step.
- If everything is ok, add a changelog line to the top of the `%changelog` section. Then commit, push and wait for [CI](https://github.com/blogc/blogc/actions).
- Create signed tag:
```
$ git tag -s -m 'blogc-0.19.0' v0.19.0 # replace with whatever version you defined before
```
This requires my (rafaelmartins) personal GPG key. If someone else needs to publish a release, please announce the new key in the blog post and GitHub release.
- Push signed tag:
```
$ git push origin v0.19.0 # replace with whatever version you defined before
```
- Wait for [CI](https://github.com/blogc/blogc/actions) to build the release files and push them to https://distfiles.rgm.io/blogc/.
## Releasing new version
- Download new release files and sign them:
```
$ ./download_release.py
```
This requires my (rafaelmartins) personal GPG key to sign files. If someone else needs to publish a release, please edit the script to add new GPG key and announce it in the blog post and GitHub release.
- Grab files from `releases/0.19.0` (replace version) and upload to GitHub release draft, including `.asc` files. The `.src.rpm` files can be omited.
- Publish release on GitHub.
- Fix blog post DATE, commit and push.
## Maintain downstream packages
- Upload `.src.rpm` file to the [official Copr](https://copr.fedorainfracloud.org/coprs/rafaelmartins/blogc/). The Copr is owned by rafaelmartins, there's no concept of organizations. I believe that an user could request publish access here: https://copr.fedorainfracloud.org/coprs/rafaelmartins/blogc/permissions/
- Prepare and submit [termux-packages](https://github.com/termux/termux-packages) pull request.
- Edit `packages/blogc/build.sh`. Update version.
- Try to build package (it will fail):
```
$ ./scripts/run-docker.sh ./build-package.sh blogc
```
- Get new SHA256 hash from last command and update `packages/blogc/build.sh`.
- Build package:
```
$ ./scripts/run-docker.sh ./build-package.sh blogc
```
- If everything builds fine, commit and create pull request.
- Bump [Gentoo package](https://packages.gentoo.org/packages/app-text/blogc). Usually just moving the ebuild and commiting is enough. rafaelmartins can push directly, someone else could need to submit patch or open pull request.
## Celebrate
\o/
|
