Release 6.5.0

[aoldershaw]

Steps for a new major/minor release:

• Create your release branch on the concourse/concourse github repo with the following format release/M.m.x (M being the major version and m being the minor version)

• Create the release branch on the concourse/concourse-bosh-release repository. Make any missing changes to the spec of web or worker depending on if the release contains any changes that adds or modifies any flags.

  • Any changes you make on the branch will not get automatically merged back to master so try to make the changes on master and then create the branch from there.
  • We should really have something that will merge the branch back to master. (like we do for the concourse/concourse branches)

• Create the release branch on concourse/concourse-bosh-deployment repository.

• Create the release branch on concourse/concourse-chart repository. Same with the concourse-bosh-release repo, make any missing changes to values.yaml or templates/web-deployment.yaml for changes to flags on web or templates/worker-deployment.yaml for changes to flags on the worker. New features to the chart are added to the dev branch vs master gets bug-fixes. This distinction should guide whether the release branch should be created from dev (major/minor release) or master (patch release).

• Bump the appropriate versions for resource types. Go to the releases page https://project.concourse-ci.org/releases and take a look at which resource type repositories have had new commits or PRs. Take a look at what those changes entail and bump the version in their respective pipeline in ci.concourse-ci.org.

  • If the changes were only README or repo restructuring changes with no user impact, you don't need to bump the version
  • If the changes were small bug fixes or changes, you can do a patch version bump
  • If the changes were adding of features, you can do a minor version bump
  • If the changes involve a breaking changes, that should be a major version bump

• Add your release pipeline to the reconfigure-pipeline

• Go through all the needs-documentation PRs in the release page for your milestone https://project.concourse-ci.org/releases/concourse?milestone=v<M.m.p> and make sure that everything has proper documentation within concourse/docs (if needed). You can organize which PRs by clicking on the button to add whichever label best fits that PR.

  • If it is already documented within concourse/docs, add a release/documented label
  • If there is no documentation and the changes have user impact that should be documented, add the documentation to concourse/docs(or delegate) then add a release/documented label after finished. E.g. the addition of a new step type ( set_pipeline step).
  • If there is no documentation and the changes have user impact that do not need to be documented, add a release/undocumented label. E.g. an experimental feature.
  • If there is no documentation and the changes do not have user impact, add a release/no-impact label. E.g. refactors.

• Once the all source code changes are finalize, Concourse RC version should be deployed to CI

  • including all the external workers (pr-worker, ci-topgun-worker, darwin-worker & BOSH deployed windows worker)

• Once the final commit has made it through the pipeline, the create-draft-release job can be triggered. This job will create a draft release within the concourse GitHub release page where you can make any final adjustments or arrangements to the generated release notes. PLEASE NOTE that any manual changes made on the draft release WILL BE OVERWRITTEN if you retrigger the create-draft-release job. Please be sure to only make manual edits AFTER you are sure this is the final run of the job.

  • If you would like to edit the content, you can directly edit the PRs that it was generated from. The title is used for each PR and also the body within the Release Note header in the PR. After you have made your edits within the PR, you can rerun the create-draft-release job in order to regenerate a new release note.
  • If you would like to change the arrangement of the PRs within the release note, you can make the edits directly on the release note of the draft release.

• Once everything is ready, the shipit job can be triggered. The publish-binaries job will convert your draft release into a final release including the body of your draft release (which will persist any changes you made to the draft release body). Subsequently, the promote concourse job will run automatically. The publish-docs job needs to be triggered manually runs automatically.

• The helm-chart pipeline is used to bump & then publish the chart.

  • First, run the merge-dev-into-master job
  • Next, run the concourse-app-bump job (bumps the app version and image to point to the latest release)
  • Finally, run the publish-chart-{major|minor|patch} job, depending on what has changed in the chart
  • If you make a major bump, be sure to update the CHANGELOG.md in the concourse-chart repo

• Once the Concourse release is shipped, Concourse should be deployed to Hush-House

[clarafu]

Okay I made a few edits to the steps, feel free to make any changes to it!

Steps for a new major/minor release:

• Once all the commits are into master for your release, create the release notes. Move the contents of release-notes/latest.md into a new release note file of release-notes/v<M.m.p>. Then create your release branch on the concourse/concourse github repo with the following format release/M.m.x (M being the major version and m being the minor version)

  • This is now automated using https://github.com/clarafu/release-me,

    ci/pipelines/release-v6.yml

    Lines 930 to 934 in f8e639f

    	- task: build-release-notes
    	file: ci/tasks/build-release-notes.yml
    	params:
    	GITHUB_TOKEN: ((concourse_github_dummy.access_token))
    	GITHUB_BRANCH: release/((release_minor)).x

    ,

    ci/tasks/scripts/build-release-notes

    Lines 6 to 12 in f8e639f

    	./release-me/releaseme generate \
    	--github-token=$GITHUB_TOKEN \
    	--github-owner=concourse \
    	--github-repo=concourse \
    	--github-branch=$GITHUB_BRANCH \
    	--last-commit-SHA=$LAST_COMMIT_SHA \
    	> built-notes/notes.md

• Create the release branch on the concourse/concourse-bosh-release repository. Make any missing changes to the spec of web or worker depending on if the release contains any changes that adds or modifies any flags.

  • Any changes you make on the branch will not get automatically merged back to master so try to make the changes on master and then create the branch from there.
  • We should really have something that will merge the branch back to master. (like we do for the concourse/concourse branches)

• Create the release branch on concourse/concourse-bosh-deployment repository.

• Create the release branch on concourse/concourse-chart repository. Same with the concourse-bosh-release repo, make any missing changes to values.yaml or templates/web-deployment.yaml for changes to flags on web or templates/worker-deployment.yaml for changes to flags on the worker. New features to the chart are added to the dev branch vs master gets bug-fixes. This distinction should guide whether the release branch should be created from dev (major/minor release) or master (patch release).

• Bump the appropriate versions for resource types. Go to the releases page https://project.concourse-ci.org/releases and take a look at which resource type repositories have had new commits or PRs. Take a look at what those changes entail and bump the version in their respective pipeline in ci.concourse-ci.org.

  • If the changes were only README or repo restructuring changes with no user impact, you don't need to bump the version
  • If the changes were small bug fixes or changes, you can do a patch version bump
  • If the changes were adding of features, you can do a minor version bump
  • If the changes involve a breaking changes, that should be a major version bump

• Add your release pipeline to the reconfigure-pipeline

• Go through all the needs-documentation PRs in the release page for your milestone https://project.concourse-ci.org/releases/concourse?milestone=v<M.m.p> and make sure that everything has proper documentation within concourse/docs (if needed). You can organize which PRs by clicking on the button to add whichever label best fits that PR.

  • If it is already documented within concourse/docs, add a release/documented label
  • If there is no documentation and the changes have user impact that should be documented, add the documentation to concourse/docs(or delegate) then add a release/documented label after finished. E.g. the addition of a new step type ( set_pipeline step).
  • If there is no documentation and the changes have user impact that do not need to be documented, add a release/undocumented label. E.g. an experimental feature.
  • If there is no documentation and the changes do not have user impact, add a release/no-impact label. E.g. refactors.

• Once the all source code changes are finalize, Concourse RC version should be deployed to CI

  • including all the external workers (pr-worker, ci-topgun-worker, darwin-worker & BOSH deployed windows worker)

• Once the final commit has made it through the pipeline, the create-draft-release job can be triggered. This job will create a draft release within the concourse GitHub release page where you can make any final adjustments or arrangements to the generated release notes. PLEASE NOTE that any manual changes made on the draft release WILL BE OVERWRITTEN if you retrigger the create-draft-release job. Please be sure to only make manual edits AFTER you are sure this is the final run of the job.

  • If you would like to edit the content, you can directly edit the PRs that it was generated from. The title is used for each PR and also the body within the Release Note header in the PR. After you have made your edits within the PR, you can rerun the create-draft-release job in order to regenerate a new release note.
  • If you would like to change the arrangement of the PRs within the release note, you can make the edits directly on the release note of the draft release.

• Once everything is ready, the shipit job can be triggered. The publish-binaries job will convert your draft release into a final release including the body of your draft release (which will persist any changes you made to the draft release body). Subsequently, the promote concourse job will run automatically. The publish-docs job needs to be triggered manually.

• The helm-chart pipeline is used to bump & then publish the chart.

• Once the Concourse release is shipped, Concourse should be deployed to Hush-House

[aoldershaw]

I've made some changes that incorporate Clara's changes directly to the issue description