Skip to content

Latest commit

 

History

History
64 lines (44 loc) · 4.75 KB

new-version-branch.md

File metadata and controls

64 lines (44 loc) · 4.75 KB

Create a New Version Branch

When doing a new release of ownCloud Infinite Scale like 5.x, a new version branch must be created based on master. It is necessary to do this in steps. Keep in mind that we only process master and the latest two versions. For older versions we only keep the pdf files statically - if possible.

Step 1: This will create and configure the new 5.x branch properly

  1. Go to the settings of this repository and check/change the protection of the branch list so that the upcoming 5.x branch can get pushed.
  2. Create a new 5.x branch based on latest origin/master
  3. Copy the .drone.star file from the former 5.x-1 branch (it contains the correct branch specific setup rules and replaces the current one coming from master)
  4. In .drone.star set latest_version to 5.x (on top in section def main(ctx)).
  5. Check in site.yml in section content.sources: that the following value is set: - url: . and in content.sources.url the following value is set: - HEAD.
  6. In antora.yml, set the version: key on top to the same as the branch name like 5.x
  7. In antora.yml, in section asciidoc.attributes, DO NOT adjust relevant -version keys. They are only used for local building.
  8. In site.yml, in section asciidoc.attributes, DO NOT adjust relevant -version keys. They are only used for local building and will be correctly set in the docs repo when doing a full build.
  9. Run a build by entering yarn antora-local. No build errors should occur.
  10. Commit the changes and push the new 5.x branch. This makes the branch available for futher processing. DO NOT CREATE A PR!

Step 2: This will configure the master branch properly to use the new 5.x branch

  1. Create new changes_necessary_for_5.x branch based on latest origin/master.
  2. In .drone.star set latest_version to 5.x (on top in section def main(ctx)).
  3. In antora.yml, check if the version: key is set to next.
  4. In site.yml and in antora.yml, DO NOT adjust relevant -version keys.
  5. Run a build by entering yarn antora. No build errors or warnings should occur.
  6. Commit changes and push them. (Check the branch protection rules upfront so that the push passes.)
  7. Create a Pull Request and see the text suggestion at the bottom. When CI is green, all is done correctly. Merge the PR to master when the 5.x branch is close to be released.

Step 3: Protection and Renaming

  1. Go to the settings of this repository and change the protection of the branch list so that the 5.x branch gets protected.
  2. Unprotect the 5.x-2 branch and rename it to x_archived_5.x-2. Note that this step can be postponed if needed. Note that after renaming, local building cant be done anymore.

Step 4: Changes in the Docs Repo

  1. In site.yml of the docs repo, adjust all -version keys in section attributes related to this repo according the new and former releases. Note that the values MUST NOT contain the trailing @. (The trailing @ character allows the value to be overwritten like from the corresponding antora.yml file which is only necessary for local building the corresponding docs-xxx repo.) Note that merging that PR should be close before publishing the relevant code release.

Step 5: Set URI latest Path Part to 5.x

  1. Nothing needs to be done there. The moment when the new server release gets tagged - which is part of the release process - latest will be automatically set to the tagged release number. This should work automatically. If not, sysadmins need to be informed to updated the underlying process.

Text Suggestion for Step 2

The following text is a copy/paste suggestion for the PR in step 2, replace the branch numbers accordingly:

These are the changes necessary to finalize the creation of the 5.x branch.

* The 5.x branch is already pushed and prepared and is included in the branch protection rules.

* When 5.x is finally out, the 5.x-2 branch can be archived, see step 3 in [Create a New Version Branch](https://github.com/owncloud/docs-ocis/blob/master/docs/new-version-branch.md)

* Note, that the 5.x branch in this repo is already created, but the `latest` pointer on the web will be set to it automatically when the tag in oics is set. This means, that in the docs homepage, `latest` will point to 5.x-1 until the tag in ocis is set accordingly. When merging this PR, 5.x-2 will be dropped from the web.

* Note that this PR must be merged **before** the 5.x tag in ocis is set to avoid a 404 for `latest`.

* Note before merging this PR, we should take care that 5.x-2 has all necessary changes merged.

@micbar fyi

@mmattel @EParzefall @phil-davis
Post merging this, we need to backport all relevant changes to 5.x