You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@openwhisk.apache.org by GitBox <gi...@apache.org> on 2019/09/23 18:11:49 UTC

[GitHub] [openwhisk-release] rabbah commented on a change in pull request #304: updated post-vote release instructions

rabbah commented on a change in pull request #304: updated post-vote release instructions
URL: https://github.com/apache/openwhisk-release/pull/304#discussion_r327255963
 
 

 ##########
 File path: docs/release_instructions.md
 ##########
 @@ -162,22 +162,89 @@ restart the process with new candidate releases.  Update your
 `config.json` file by incrementing the `rc` number and changing git
 hashes.
 
-### Publishing a Successful Release
-
-TODO: This portion of the documentation and scripting still needs to be updated.
-
-  10. [Publish the release artifacts to Apache release directory](publish_apache_directory.md)
-      You should receive an email from reporter.apache.org asking you to add your version data
-      to its database shortly after you commit to the dist svn.  Please follow the link and
-      add the information (this is useful for generating board reports).
-  11. [Tag the commit IDs in the Github repository for the project](tag_release.md)
-  12. [Generate the release notes](generate_release_notes.md)
-  13. If appropriate, update dockerhub `latest` tags.
-  14. If appropriate update deploy-kube and docker-compose tag info to pick up new images.
-  15. Submit a PR to update the downloads page.
-
-  20. Announce the release -- must wait until website PR is merged and Jenkins publishes site.
-  30. Cleanup the artifacts from the release process:
-      a. Remove the rc files from staging.
-      b. Remove the previous If there is a previous released version, remove it from Apache release directory
-         (it will automatically still be available via the Apache archive server).
+### Publishing a Successful Release to Apache Dist Servers
+
+After a successful vote, the release manager will commit the artifacts
+being released to the openwhisk subdir of the Apache dist svn.
+
+The upload_to_dist.sh script automates the copy & svn add operations, but it
+assumes that every file found in the release candidate subdir should be released.
+If this is not true (eg multiple parallel release votes), then the upload
+must be performed manually.
+```
+./upload_to_dist.sh ../release-configs/<MY_RELEASE_CONFIG>.json
+```
+
+Assuming the expected set of files were added, commit them:
+```
+cd ../stagingArea/svn_release && svn commit -m  "Apache OpenWhisk X.Y.Z release of <Component Description>"
+```
+
+Relatively soon after doing the svn commit, you should receive an email from
+from reporter.apache.org asking you to add your version data
+to its database.  Please follow the link and add the information
+(the data is used to generate periodic reports to the ASF Board).
+
+### Tag GitHub repos
+
+Each GitHub repository needs to be tagged.  Unfortunately, the naming conventions for
+tagging vary across the OpenWhisk project repositories and therefore we have not
+yet attempted to automate this step.
+
+For each released repository, the Release Manager should examine the existing set of
+tags (`git tag`) and then add a new tag following the same convention using the
+git commit hash from <MY_RELEASE_CONFIG>.json.  After tagging a repo, push the tag.
+
+Many of the GitHub repositories are configured to build binary artifacts in response
+to new tags being committed.  Monitor the build process and ensure that all expected
+artifacts are created for each tag you commit.
+
+There are some slightly outdated, but much more detailed comments
+on [release tagging](tag_release.md) available if you need a reminder
+of the git commands to use.
+
+### Create GitHub releases
+
+After pushing the tags, you should go to the GitHub Releases for
+each released project and "Draft a new release" using the tag you just
+pushed. If the project contains a CHANGELOG or RELEASENOTES, copy that
+information into the release description.
+
+### Dockerhub updates
+
+If the components you released build docker images, then you should
+build the docker images locally, tag them with the release version
+(following the naming scheme for the repo), push the new images to
+dockerhub using the whiskbot dockerhub id, and update the `latest`
+tag to point to the new images.
+
+If you have published new images to dockerhub, submit PRs to openwhisk-deploy-kube
+and openwhisk-devtools (docker-compose) to use the new images.
 
 Review comment:
   ```suggestion
   and [openwhisk-devtools (docker-compose)](https://github.com/apache/openwhisk-devtools) to use the new images.
   ```

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services