Skip to content

Commit b3df4c3

Browse files
authored
Update the RELEASING docs to cover the current state of things. (#1759)
1 parent d72aed9 commit b3df4c3

File tree

1 file changed

+23
-32
lines changed

1 file changed

+23
-32
lines changed

Documentation/RELEASING.md

+23-32
Original file line numberDiff line numberDiff line change
@@ -18,55 +18,46 @@ When doing a release:
1818
and include a reference '#XYZ', this tells you what pull request it was part of. This is useful
1919
for doing the release notes in the next section.
2020

21-
1. Validate the versions numbers
21+
1. Update the version on _main_
2222

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+
```
2526

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.
3033

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.
3236

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.
3938

4039
1. Create a release on github
4140

4241
Top left of the [project's releases page](https://github.com/apple/swift-protobuf/releases)
4342
is _Draft a new release_.
4443

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.
4750

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_.
5052

5153
1. Publish the `SwiftProtobuf.podspec`
5254

55+
_Note:_ You must be an _owner_ of the pod to do this, see `pod trunk info SwiftProtobuf`
56+
for who are owners.
57+
5358
```
5459
pod trunk push SwiftProtobuf.podspec
5560
```
5661
5762
_Note:_ This uses that local copy of `SwiftProtobuf.podspec`, but checks
5863
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

Comments
 (0)