azagrebin commented on a change in pull request #18: URL: https://github.com/apache/flink-docker/pull/18#discussion_r420860229
########## File path: README.md ########## @@ -39,24 +50,30 @@ There are additional steps required when a new Flink minor version (x.y.0) is re ### Release workflow -When a new release of Flink is available, the Dockerfiles in this repo should be updated and a new +When a new release of Flink is available, the Dockerfiles in the `master` branch should be updated and a new manifest sent to the Docker Library [`official-images`]( https://github.com/docker-library/official-images) repo. -Updating the Dockerfiles involves 3 steps: - -1. Update `add-version.sh` with the GPG key ID of the key used to sign the new release - * Commit this change with message `Add GPG key for x.y.z release` <sup>\[[example]( - https://github.com/apache/flink-docker/commit/94845f46c0f0f2de80d4a5ce309db49aff4655d0)]</sup> -2. Remove any existing Dockerfiles from the same minor version - * e.g. `rm -r 1.2`, if the new Flink version is `1.2.1` -3. Run `add-version.sh` with the appropriate arguments (`-r flink-minor-version -f - flink-full-version`) - * e.g. `./add-version.sh -r 1.2 -f 1.2.1` - * Commit these changes with message `Update Dockerfiles for x.y.z release` <sup>\[[example]( +The Dockerfiles are generated on the respective `dev-<version>` branches, and copied over to the `master` branch for +publishing. + +Updating the Dockerfiles involves the following steps: + +1. Generate the Dockerfiles + * Checkout the `dev-x.y` branch of the respective release, e.g., dev-1.9 + * Update `add-version.sh` with the GPG key ID of the key used to sign the new release Review comment: do we need to keep GPG keys in repo mostly for CI? ########## File path: README.md ########## @@ -24,6 +24,17 @@ Flink Docker image lifecycle https://github.com/docker-library/official-images/blob/master/library/flink). +Development workflow +---------------------------- + +The `master` branch of this repository serves as a pure publishing area for releases. + +Development happens on the various `dev-X` branches. + +Pull requests for a specific version should be opened against the respective `dev-<version>` branch. +Pull requests for all versions, or for the next major Flink release, should be opened against the `dev-master` branch. Review comment: It would be nice to add some details about which flink dist is tested by CI on dev branches. It looks that the `dev-1.X` branches run CI always against the last release and not its snapshots, like in `dev-master`, do we want this? This makes sense to check changes for generating other Dockerfile for the current minor release but it does not prepare for the next minor release using major release snapshots ########## File path: README.md ########## @@ -79,14 +96,17 @@ available shortly thereafter. ### Release checklist +Checklist for the `dev` branch: - [ ] The GPG key ID of the key used to sign the release has been added to `add-version.sh` and committed with the message `Add GPG key for x.y.z release` +- [ ] `./add-version.sh -r x.y -f x.y.z` has been run on the respective dev branch + +Checklist for the `master` branch: +- [ ] The updated Dockerfiles have been committed with the message `Update Dockerfiles for x.y.z release` Review comment: I think this step `updated Dockerfiles` should be either after or merged into the current 3rd step: `_(new patch releases only)_ any existing generated files for the same minor version have been removed` as before the step `./add-version.sh..` was. As I understand new `x.y.z` overwrites the previous `x.y.(z-1)`. Otherwise, it is confusing, imo ---------------------------------------------------------------- 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: [email protected]
