@@ -18,55 +18,46 @@ When doing a release:
18
18
and include a reference '#XYZ', this tells you what pull request it was part of. This is useful
19
19
for doing the release notes in the next section.
20
20
21
- 1 . Validate the versions numbers
21
+ 1 . Update the version on _ main _
22
22
23
- 1 . Inspect ` Sources/SwiftProtobuf/Version.swift ` and ensure the number is what you expect for
24
- the next release.
23
+ ```
24
+ DevTools/LibraryVersions.py [a.b.c]
25
+ ```
25
26
26
- Normally we try to bump _ main_ to a new revision after each release, so this number may
27
- be fine, but if this release includes import things (api changes, etc.), it may make sense
28
- to go back and bump the _ major_ or _ minor_ number instead. If you do need to change the
29
- number: ` DevTools/LibraryVersions.py a.b.c ` .
27
+ If you aren't sure if ` b ` or ` c ` , rather then checking all the _ semver_ tags on the
28
+ PRs, you can use the [ project's releases page] ( https://github.com/apple/swift-protobuf/releases )
29
+ and _ Draft a new release_ ; fill in _ 99.99_ for that tag, and then click the _ Generate
30
+ release notes_ button, it will include sections based on the _ semver_ tags to indicate
31
+ which segment * must* be updated. If you do this * discard* this draft as you don't
32
+ actually want to create a _ 99.99_ release later on.
30
33
31
- 1 . Run our tool to ensure the versions are all in sync:
34
+ _ Note:__ ` a ` is really rare since it is a major version bump usually reserved for
35
+ breaking changes as it has a cost on all things that depend on this repo.
32
36
33
- ```
34
- DevTools/LibraryVersions.py --validate
35
- ```
36
-
37
- This will run silently if everything was ok; if something was wrong, you'll need to figure
38
- out why and get things back in sync.
37
+ * Import* Make sure to commit/merge this _ main_ on github.
39
38
40
39
1 . Create a release on github
41
40
42
41
Top left of the [ project's releases page] ( https://github.com/apple/swift-protobuf/releases )
43
42
is _ Draft a new release_ .
44
43
45
- The tag should be `[a.b.c]` where the number *exactly* matches one you examined in
46
- `Sources/SwiftProtobuf/Version.swift`.
44
+ The tag should be ` [a.b.c] ` where the number * exactly* matches one you used in the
45
+ previous step (and just committed to the repo).
46
+
47
+ For the description click the _ Generate release notes_ button. That should do
48
+ everything based on the PR descriptions and _ semver_ tags in the repo. Just read
49
+ though was was generate to see if any tweaks are needed.
47
50
48
- For the description call out any major things in that release. Usually a short summary and
49
- then a reference to the pull request for more info is enough.
51
+ When everything is good, click on _ Publish release_ .
50
52
51
53
1 . Publish the ` SwiftProtobuf.podspec `
52
54
55
+ _ Note:_ You must be an _ owner_ of the pod to do this, see ` pod trunk info SwiftProtobuf `
56
+ for who are owners.
57
+
53
58
```
54
59
pod trunk push SwiftProtobuf.podspec
55
60
```
56
61
57
62
_Note:_ This uses that local copy of `SwiftProtobuf.podspec`, but checks
58
63
against the sources on github.
59
-
60
- 1. Bump the version on _main_
61
-
62
- To help tell if someone is using _main_ before it has been cut as a release, go ahead and
63
- bump it to a new revision:
64
-
65
- ```
66
- DevTools/LibraryVersions.py [ a.b.c]
67
- ```
68
-
69
- Where _c_ is one higher than the release that was just done.
70
-
71
- Make sure to commit/merge this _main_ on github.
72
-
0 commit comments