Update how to release instructions with more details #210
Conversation
jackye1995
force-pushed
the
update-how-to-release
branch
from
e86be32 to
6a47851
Compare
| ```shell | ||
| rm -rf ../iceberg-docs/docs/content | ||
| cp -r ../iceberg/docs ../iceberg-docs/docs/content | ||
| ``` | ||
| 3. Commit the changes and open a PR against the `<VERSION>` branch in the `iceberg-docs` repo |
There was a problem hiding this comment.
In the new workflow described here, we do everything against main, and in the end cut the version branch and sync latest branch, this avoids unnecessary commit conflicts and need to do branch merges.
| ```shell | ||
| cd ../iceberg | ||
| echo "<VERSION>" > version.txt |
There was a problem hiding this comment.
this makes sure the version number is correct for the javadoc folder
|
|
||
| Once the common docs changes have been merged into `main`, the next step is to update the versioned docs. | ||
| #### Copy versioned documentations |
There was a problem hiding this comment.
We could also build a github action in Iceberg repo to sync latest docs and javadoc to here right after a new change. Not sure if there is any way for the github action to commit to this repo or create a PR though.
There was a problem hiding this comment.
Apparently yes, https://github.com/marketplace/actions/create-pull-request
There was a problem hiding this comment.
let me ping Infra team to see if this action can be used, and if it has required permissions
| There are a few places in the codebase that reference the latest Iceberg release version number and need to be updated: | ||
| 1. https://github.com/apache/iceberg/blob/master/.github/ISSUE_TEMPLATE/iceberg_bug_report.yml | ||
| 2. https://github.com/apache/iceberg/blob/master/python/dev/Dockerfile | ||
| 3. `oldVersion` in `revapi` in https://github.com/apache/iceberg/blob/master/build.gradle |
There was a problem hiding this comment.
Do we need to modify all these values in the release commit?
There was a problem hiding this comment.
What do you mean by release commit?
I think this can only be changed after the artifact is released and fully published, so there is a period of time that we have released but still cannot consume the artifact.
There was a problem hiding this comment.
I guess I'm just confused about what these instructions are telling me to do, like after release am I making a new commit that updates these things?
There was a problem hiding this comment.
usually we did those updates after a release (at least the revApi oldVersion bump you can only do after artifacts are available). The same applies for the docker file and the docker compose that have been upgraded in apache/iceberg#7164.
For the docker compose to actually work with the latest Iceberg version, I was updating databricks/docker-spark-iceberg#72 and databricks/iceberg-rest-image#7
|
@nastra could you take a look to see if the proposed update would work based on your release experience? |
|
@jackye1995 should we maybe first get #187 in? @gaborkaszab was doing the previous release and also added a few good items there |
Oh sorry totally overlooked this. @gaborkaszab is it okay if I just include your content there and mark you as coauthor? Otherwise many changes will need to resolve conflict |
|
Hey @jackye1995 , |
Co-authored-by: Eduard Tudenhoefner <etudenhoefner@gmail.com>
|
@jackye1995 Thanks for creating this PR. I'd love to get this in since we've forgotten to update the Github releases for the last two releases. Would you have time to resolve the conflicts? |
|
Had conflicts with how-to-release |
| evolution. | ||
|
|
||
| This release can be downloaded from: https://www.apache.org/dyn/closer.cgi/iceberg/<TARBALL NAME WITHOUT .tar.gz>/<TARBALL NAME> | ||
|
|
There was a problem hiding this comment.
I saw that recently there's release notes link in the email, can we also add that?
There was a problem hiding this comment.
Looks like great to get in, left a few comments.
I also had a lot of pain around documentation part of the release process. I put some issues I faced here, apache/iceberg#8151 , and am curious if this would solve some of them.
Also we can double check whether these steps make sense for patch-release, and not major release.
|
|
||
| #### Versioned documentation update | ||
| Raise a PR with the specific changes against `main` branch and merge. |
There was a problem hiding this comment.
Does this differ for patch release vs non-patch release?
| there are a few places in the codebase that reference the latest Iceberg release version number and need to be updated: | ||
| 1. Update `options` list for `Apache Iceberg version` in https://github.com/apache/iceberg/blob/master/.github/ISSUE_TEMPLATE/iceberg_bug_report.yml | ||
| 2. Update `ICEBERG_VERSION` in https://github.com/apache/iceberg/blob/master/python/dev/Dockerfile | ||
| 3. Update `oldVersion` in `revapi` in https://github.com/apache/iceberg/blob/master/build.gradle |
There was a problem hiding this comment.
Looks like we should make a note to not do this for patch release: apache/iceberg#8150 (comment)
| ``` | ||
|
|
||
| Then release the candidate repository in [Nexus](https://repository.apache.org/#stagingRepositories). | ||
| Then create a new GitHub release in https://github.com/apache/iceberg/releases from the release version tag. |
There was a problem hiding this comment.
Looks like we can be a bit more consistent with release name, how about specify to call it Apache Iceberg <VERSION>
|
@jackye1995, I'll be updating how to release for the docs section. Once I'm done with that, would you mind moving this over to https://github.com/apache/iceberg/pulls please? |
No description provided.