Document a release process. #579
Conversation
Documentation/INTERNALS.md
Outdated
|
|
||
| 1. Examine what has changed | ||
|
|
||
| Githubs compre UI does a reasonable job here. [Open that UI](https://github.com/apple/swift-protobuf/compare) |
Documentation/INTERNALS.md
Outdated
| then a reference to the pull request for more info is enough. | ||
|
|
||
| _Note:_ If we end up including a prebuilt `protoc-gen_swift` (or any other binaries) in the | ||
| releases; they also can be attached at this point. |
There was a problem hiding this comment.
I'm not thrilled about getting into the business of shipping binaries. The packaging folks already do this very well.
There was a problem hiding this comment.
Dropping this comment. I had it because #7 is open about providing them. Do we want to just close that as not gonna do it?
There was a problem hiding this comment.
That would be my preference, yes.
Documentation/INTERNALS.md
Outdated
| 1. Inspect `Sources/SwiftProtobuf/Version.swift` and ensure the number is what you expect for | ||
| the next release. | ||
|
|
||
| Normally we try to bump _master_ to a new revision after each release, so this number may |
There was a problem hiding this comment.
This makes me a little nervous: SwiftPM works directly off of git tags (not "releases") so will happily let people grab tags from master. Master may have (hopefully temporary) API breakage or other significant problems. So tagging master and then inheriting that version number in a release branch may be tricky. I'm not sure whether there are good alternatives, though.
There was a problem hiding this comment.
I'm not following.
github's "releases" are basically a tag with some web ui and the auto creation of tar/zip files of the bits for folks to download.
There are two other patterns I've seen for this:
- Use even revisions for the pending state and odd for the released state.
- Use zero as the master branch, and all release have a non zero revision.
Both allow you to always tell if some was using master directly or not. But both add complexity in how you cut a release.
Thoughts?
There was a problem hiding this comment.
Not really a problem today, since I don't expect us to have any API-breaking changes even in master for a little while. Once that happens, we'll have to consider how to manage the divergence between master and the 1.x release branch.
Documentation/INTERNALS.md
Outdated
|
|
||
| 1. Publish the CocoaPod | ||
|
|
||
| 1. Do a final sanity check that CocoaPods is happy with the release you just made, in the project |
There was a problem hiding this comment.
Great! I'm not that familiar with CocoaPods; this helps a lot.
Documentation/INTERNALS.md
Outdated
| @@ -451,3 +451,94 @@ TODO | |||
|
|
|||
| TODO | |||
|
|
|||
| # Releasing | |||
There was a problem hiding this comment.
I think it might make more sense to have this as a separate RELEASE.md document.
Documentation/RELEASING.md
Outdated
|
|
||
| 1. Examine what has changed | ||
|
|
||
| Githubs compare UI does a reasonable job here. [Open that UI](https://github.com/apple/swift-protobuf/compare) |
I did a push of the spec as part of validating things, so folks can get the spec directly from the cocoapods spre repo.
No description provided.