From cce6bca99610e6661c4bbea3d8f04a6d70df289a Mon Sep 17 00:00:00 2001 From: Mark Ackert Date: Wed, 10 Oct 2018 14:49:45 -0400 Subject: [PATCH 01/13] install and enable dco script for batch + shell Signed-off-by: Mark Ackert --- scripts/dco/enable_dco.bat | 31 +++++++++++++++++++++++++++++++ scripts/dco/enable_dco.sh | 28 ++++++++++++++++++++++++++++ 2 files changed, 59 insertions(+) create mode 100644 scripts/dco/enable_dco.bat create mode 100644 scripts/dco/enable_dco.sh diff --git a/scripts/dco/enable_dco.bat b/scripts/dco/enable_dco.bat new file mode 100644 index 0000000..aef6c26 --- /dev/null +++ b/scripts/dco/enable_dco.bat @@ -0,0 +1,31 @@ +@ECHO OFF +REM Check if dco exists. If so, run enable. +WHERE dco >nul 2>nul +IF %ERRORLEVEL% EQU 0 ( + dco enable +) ELSE ( + REM If dco is not installed, check for ruby and try to install it. Otherwise print ruby install instructions. + WHERE ruby >nul 2>nul + IF ERRORLEVEL 0 ( + echo "Installing coderanger/dco..." + gem install dco + REM Rather than re-run the script from the top, lets enable dco after the initial install. + CALL :postInstallDcoEnable + ) ELSE ( + echo "Ruby not found. Ruby is required to use the coderanger/dco signing tool." + echo 'To install Ruby, visit https://www.ruby-lang.org/en/downloads/.' + echo "Once Ruby is installed, open a new shell session and rerun this script." + ) +) + + +REM If dco is installed by this script, run this function afterwards to enable dco. If dco fails or cannot be found, +REM then users will need to investigate their local environment. +::postInstallDcoEnable +:postInstallDcoEnable +WHERE dco >nul 2>nul +IF %ERRORLEVEL% EQU 0 ( + dco enable +) ELSE ( + echo '"dco" command was not found. Please check your gem modules for dco. ("gem query --local")' +) diff --git a/scripts/dco/enable_dco.sh b/scripts/dco/enable_dco.sh new file mode 100644 index 0000000..3c0ddd7 --- /dev/null +++ b/scripts/dco/enable_dco.sh @@ -0,0 +1,28 @@ +#! /bin/sh + +# If dco is installed by this script, run this function afterwards to enable dco. If dco fails or cannot be found, +# then users will need to investigate their local environment. +postInstallDcoEnable () { + if hash dco 2>/dev/null; then + dco enable + else + echo '"dco" command was not found. Please check your gem modules for dco. ("gem query --local")' + fi +} + +# Check if dco exists. If so, run enable. +if hash dco 2>/dev/null; then + dco enable +else + # If dco is not installed, check for ruby and try to install it. Otherwise print ruby install instructions. + if hash ruby 2>/dev/null; then + echo "Installing coderanger/dco..." + gem install dco + # Rather than re-run the script from the top, lets enable dco after the initial install. + postInstallDcoEnable + else + echo "Ruby not found. Ruby is required to use the coderanger/dco signing tool." + echo 'To install Ruby, visit https://www.ruby-lang.org/en/downloads/.' + echo "Once Ruby is installed, open a new shell session and rerun this script." + fi +fi \ No newline at end of file From 94ef59fcf6a5da2b560e9077be60839a52cf8e1c Mon Sep 17 00:00:00 2001 From: Mark Ackert Date: Thu, 25 Oct 2018 11:22:59 -0400 Subject: [PATCH 02/13] initial incomplete draft Signed-off-by: Mark Ackert --- process/MigrationPlan.md | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 process/MigrationPlan.md diff --git a/process/MigrationPlan.md b/process/MigrationPlan.md new file mode 100644 index 0000000..d6e8b22 --- /dev/null +++ b/process/MigrationPlan.md @@ -0,0 +1,37 @@ +# Build Migration + +| Repository Name | Blocking Infrastructure | Migration Status | Comments and Notes | +|---|---|---|---| +| imperative | distributed | ready | [Imperative Notes](###Imperative) | +| zowe-cli | z/OS | blocked | [Zowe-CLI Notes](###Zowe-CLI) | +| docs-site | distributed | ready | May require additional pay-for tooling? | +| zowe-cli-profile-migration | distributed | blocked | No build exists yet | +| zlc | n/a | n/a | n/a | +| explorer-jes | distributed | ready | [Explorer-JES Notes](###Explorer-jes) | +| zlux | z/OS | pending review | [ZLUX Notes](###zlux) | + + +### Imperative +The imperative repository has no dependencies on z/OS infrastructure, and should be moved immediately. +**Open Question: Where do we publish the build binary?** + +### Zowe-CLI +The zowe-cli project requires z/OS Infrastructure for system tests, and the build currently runs on proprietary machines. +z/OS Software required: z/OSMF, TSO, USS, PLEX (MONOPLEX may be acceptable). +z/OS Security requirements: A user with the ability to execute z/OSMF REST APIs, including job submission and console command execution. + +### Explorer-jes +Where do we publish the build binary? (Probably Sonatype) +Straightforward migration, move early? + +### zlux +The zlux build refers to multiple subprojects and repositories, as the zlux is a git superproject. +The repositories covered by the zlux build are as follows: +| Name | +|---| +| zos-subsystems | + + + + + From 64b9175d1faed78df5652ba0c20f669786ca0391 Mon Sep 17 00:00:00 2001 From: Mark Ackert Date: Tue, 30 Oct 2018 09:28:10 -0400 Subject: [PATCH 03/13] Init release process README Signed-off-by: Mark Ackert --- process/ReleaseProcess.md | 65 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 process/ReleaseProcess.md diff --git a/process/ReleaseProcess.md b/process/ReleaseProcess.md new file mode 100644 index 0000000..f58388d --- /dev/null +++ b/process/ReleaseProcess.md @@ -0,0 +1,65 @@ +# Release Process and Guidelines + + +## What is a Zowe release? + +A release of the Zowe project contains two 'convenience' deliverables - CLI binaries, and a PAX file which contains the Zowe API Mediation Layer, Zowe Desktop, and Zowe Explorer-Server. The CLI binaries are obtainable either through standard npm install commands, or, for users with limited internet access, through a convience zip file which allows for offline installation. The CLI convenience zip and Zowe PAX are both available through the official [Zowe Website](https://www.zowe.org). + +Each Zowe release comes with updates to user installation, configuration, and extension documentation. The documentation is developed in the [docs-site repository](https://github.com/zowe/docs-site), is accessible through the [Zowe Website](https://www.zowe.org), and is hosted directly on [Github.io](https://zowe.github.io/docs-site/). + +The focus of this document refers to generating stable releases of Zowe. For bleeding edge Zowe builds, see [Zowe Nightly Builds](##Zowe%20Nightly%20Builds). + +Generating any release of Zowe requires gathering artifacts from each of Zowe's subprojects, organizing them into the Zowe deliverables, testing said Zowe deliverables, signing the deliverables, and publishing the deliverables in sync with Release Notes / Documentation Updates. + +## How do we generate a release? + +In order to generate a new release of Zowe, each of the below checklists must be completed. The checklists below are roughly ordered based on prerequisite resolution. + +### Subproject Checklist. + +* Each subproject **must** confirm the version(s) of their planned deliverable artifacts. **Official Zowe deliverables must not depend on SNAPSHOTS or other imprecise artifact versioning schemas**. For details, see [Subproject Release Cadence](##Subproject%20Release%20Cadence). +* Each subproject **must** identify if any of their dependencies have changed since the last release. +* Each subproject **must** create release notes for their project. For details, see [Creating Release Notes](##Creating%20Release%20Notes) + +### Zowe CLI Convenience Bundle Checklist + +* Confirm @next versions of the core CLI as well as plugins for packaging. + +### Zowe Documentation Checklist + +* Aggregate release notes from the Zowe subprojects, and place them in the [docs-site repository](https://github.com/zowe/docs-site). +* Merge release notes and any other docs-site feature branches into the [docs-staging branch](https://github.com/zowe/docs-site/tree/docs-staging). + +### Zowe PAX Checklist + +* Build PAX +* Test PAX + * Publish as RC candidate + * Test RC candidate + * Automated smoke tests + * Manual verifications + * Loop if necessary until candidate passes +* Sign the PAX + +### Publish Release Checklist + +* Publish signed PAX file to gizafoundation.org . +* Publish Zowe CLI bundle to Zowe.org website +* Update zowe.org website with new version information. +* Publish new documentation. +* Publish announcements (slack, mailing lists, elsewhere?). +* + +## Subproject Release Cadence +Stable Zowe releases **must** contain artifacts which have stable, addressable versions. Therefore, it is **recommended** that Zowe subprojects publish release versions in accordance with [Semantic Versioning](https://semver.org) guodelines. Pre-release or build metadata formats (1.0.0-xyz.date, 1.0.0+xyz.date) are conditionally acceptable as stable versions. Less precise formats such as the Maven 'SNAPSHOT' format are not acceptable as they cannot refer to a static artifact level. + +This guide does not dictate stable release cadence nor how to achieve said cadence, though frequent releases are preferable. For implemented examples on frequent release cadence, see the [Zowe CLI Subproject](https://github.com/Zowe/zowe-cli) or ???. + +## Creating Release Notes +Release notes must have a human-readable summary of major changes compared to the prior release. +Release notes must also identify every publicly known vulnerability with a matching CVE assignment. + +## Zowe Nightly Builds +Zowe Nightly Builds may contain those less specific versions schemas that the stable release bans. Nightly builds are available for public consumption, but may contain bugs or incomplete features. + +The nightly build allows subprojects to gain a head start on their release process, as they can download the nightly build at any time to test their bleeding edge components. If the nightly build is too unstable to be valuable to a subproject, then they should coordinate with the CI/CD team to create a PAX branch off of master. They can use this branch to test their components integration with the Zowe PAX before pushing the latest component to master. \ No newline at end of file From 72f9214178b7944ac34665aed35190f427fdae4d Mon Sep 17 00:00:00 2001 From: "Jack (T.) Jia" <39711029+jackjia-ibm@users.noreply.github.com> Date: Tue, 30 Oct 2018 14:10:00 -0400 Subject: [PATCH 04/13] add branch model Signed-off-by: Jack (T.) Jia --- process/ReleaseProcess.md | 104 ++++++++++++++++++++++++++++++++++---- 1 file changed, 93 insertions(+), 11 deletions(-) diff --git a/process/ReleaseProcess.md b/process/ReleaseProcess.md index f58388d..b1350a5 100644 --- a/process/ReleaseProcess.md +++ b/process/ReleaseProcess.md @@ -7,19 +7,21 @@ A release of the Zowe project contains two 'convenience' deliverables - CLI bina Each Zowe release comes with updates to user installation, configuration, and extension documentation. The documentation is developed in the [docs-site repository](https://github.com/zowe/docs-site), is accessible through the [Zowe Website](https://www.zowe.org), and is hosted directly on [Github.io](https://zowe.github.io/docs-site/). -The focus of this document refers to generating stable releases of Zowe. For bleeding edge Zowe builds, see [Zowe Nightly Builds](##Zowe%20Nightly%20Builds). +The focus of this document refers to generating stable releases of Zowe. For bleeding edge Zowe builds, see [Zowe Nightly Builds](#zowe-nightly-builds). Generating any release of Zowe requires gathering artifacts from each of Zowe's subprojects, organizing them into the Zowe deliverables, testing said Zowe deliverables, signing the deliverables, and publishing the deliverables in sync with Release Notes / Documentation Updates. ## How do we generate a release? +Stable Zowe releases are generated from [zowe-install-packaging](https://github.com/zowe/zowe-install-packaging) repository **master** branch. The versions defined in [zowe-install-packaging](https://github.com/zowe/zowe-install-packaging) are Zowe official stable version. + In order to generate a new release of Zowe, each of the below checklists must be completed. The checklists below are roughly ordered based on prerequisite resolution. ### Subproject Checklist. -* Each subproject **must** confirm the version(s) of their planned deliverable artifacts. **Official Zowe deliverables must not depend on SNAPSHOTS or other imprecise artifact versioning schemas**. For details, see [Subproject Release Cadence](##Subproject%20Release%20Cadence). +* Each subproject **must** confirm the version(s) of their planned deliverable artifacts. **Official Zowe deliverables must not depend on SNAPSHOTS or other imprecise artifact versioning schemas**. For details, see [Subproject Release Cadence](#subproject-release-cadence). * Each subproject **must** identify if any of their dependencies have changed since the last release. -* Each subproject **must** create release notes for their project. For details, see [Creating Release Notes](##Creating%20Release%20Notes) +* Each subproject **must** create release notes for their project. For details, see [Creating Release Notes](#creating-release-notes) ### Zowe CLI Convenience Bundle Checklist @@ -43,23 +45,103 @@ In order to generate a new release of Zowe, each of the below checklists must be ### Publish Release Checklist -* Publish signed PAX file to gizafoundation.org . -* Publish Zowe CLI bundle to Zowe.org website -* Update zowe.org website with new version information. +* Publish signed PAX file to https://projectgiza.org website. +* Publish Zowe CLI bundle to https://projectgiza.org website. +* Update zowe.org website with new version information on both PAX file and CLI bundle. * Publish new documentation. -* Publish announcements (slack, mailing lists, elsewhere?). -* +* Publish announcements (slack, mailing lists, zowe.org home page, elsewhere?). ## Subproject Release Cadence -Stable Zowe releases **must** contain artifacts which have stable, addressable versions. Therefore, it is **recommended** that Zowe subprojects publish release versions in accordance with [Semantic Versioning](https://semver.org) guodelines. Pre-release or build metadata formats (1.0.0-xyz.date, 1.0.0+xyz.date) are conditionally acceptable as stable versions. Less precise formats such as the Maven 'SNAPSHOT' format are not acceptable as they cannot refer to a static artifact level. + +Stable Zowe releases **must** contain artifacts which have stable, addressable versions. Therefore, it is **recommended** that Zowe subprojects publish release versions in accordance with [Semantic Versioning](https://semver.org) guidelines. Pre-release or build metadata formats (1.0.0-xyz.date, 1.0.0+xyz.date) are conditionally acceptable as stable versions. Less precise formats such as the Maven 'SNAPSHOT' format are not acceptable as they cannot refer to a static artifact level. This guide does not dictate stable release cadence nor how to achieve said cadence, though frequent releases are preferable. For implemented examples on frequent release cadence, see the [Zowe CLI Subproject](https://github.com/Zowe/zowe-cli) or ???. ## Creating Release Notes + Release notes must have a human-readable summary of major changes compared to the prior release. Release notes must also identify every publicly known vulnerability with a matching CVE assignment. +## Repository Branch Versioning Cadence + +Zowe itself has own version life cycle, along with each subprojects may have independent cycles. The version life cycle is a combination of repository branches and dependencies of certain version of subprojects which represented as artifactory folders or npm registry entries. + +There are 3 suggested types of branches related to the versions, and each project may choose what best fit in the subproject. + +- **master**, which is always the latest stable build, +- **v?.?.x**, which is Long-Time-Support build thread, which we can continue build LTS versions and apply patches to it. These branches are optional, and created based on needs. +- **v?.?.?-staging**, which is future version, and some feature targets for that version, not current stable, should be merged into this branch. These branches are optional, and created based on needs. + +For each stable version released from **master** branch, the repository should have a proper git tag for the version created. + +The branch model is intended to protect **master** branch for building stable version and add ability to continue build on LTS versions. + +### Zowe Branches + +Here is a brief graph of how the branches and artifactory folders orchestrated together to final Zowe stable and staging builds. + +``` +├─ branch master: on v1.0.3, build results are published to artifactory snapshots/org/zowe/1.0.3-snapshot/ and prmoted to artifactory releases/org/zowe/1.0.3/ +│ ├── subproject1 v0.1.2 +│ ├── subproject2 v3.4.5 +│ │ ├── subproject2-1 v2.1.0 +│ │ ├── subproject2-2 v2.2.0 +│ │ └── subproject2-3 v2.3.0 +│ ├── subproject3 v6.7.8 +│ └── subproject4 v9.10.11 +├─ branch v0.9.x: on v0.9.20, build results are published to artifactory snapshots/org/zowe/0.9.20-snapshot/ and prmoted to artifactory releases/org/zowe/0.9.20/ +│ ├── subproject1 v0.0.15 +│ ├── subproject2 v3.1.0 +│ │ ├── subproject2-1 v1.1.0 +│ │ ├── subproject2-2 v1.2.0 +│ │ └── subproject2-3 v1.3.0 +│ ├── subproject3 v5.6.7 +│ └── subproject4 v8.9.10 +├── brnach v1.0.4-staging: on v1.0.4, build results are published to artifactory snapshots/org/zowe/1.0.4-staging/ +│ ├── subproject1 v0.1.3 +│ ├── subproject2 v3.7.0 +│ │ ├── subproject2-1 v2.10.0 +│ │ ├── subproject2-2 v2.20.0 +│ │ └── subproject2-3 v2.30.0 +│ ├── subproject3 v6.7.8 +│ └── subproject4 v9.10.12 +└── branch v1.1-staging: on v1.1.0, build results are published to artifactory snapshots/org/zowe/1.1-staging/ + ├── subproject1 v1.0.2 + ├── subproject2 v4.1.0 + │ ├── subproject2-1 v3.1.0 + │ ├── subproject2-2 v3.2.0 + │ └── subproject2-3 v3.3.0 + ├── subproject3 v6.7.8 + ├── subproject4 v10.0.5 + └── subproject5 v0.1.2 +``` + +- Any changes which is not supposed to be included in v1.0.3 build, **SHOULD NOT** be merged into **master** branch. If it intends to be in next build, the pull request should be merged into **v1.0.4-staging** branch. +- The first commit in **v1.0.4-staging** branch **SHOULD** be bumping version to v1.0.4. +- After **v1.0.4-staging** branch is merged into **master**, **v1.0.4-staging** branch **SHOULD** be deleted. Now **master** branch will generate v1.0.4 builds. +- Before **v1.1-staging** branch, which is a staging branch on `minor` version level, merged into **master**, we **SHOULD** create a side branch name **v1.0.x** for long term support and build future v1.0.? version. + +### Subproject Branches + +For each of the subprojects, may follow similar pattern. But subproject itself may decide which version (major, minor or path) level it needs for staging branches and if they need legacy version branches. Here is example of subproject repository which creates staging branches on `minor` level: + +``` +├─ branch master: on v4.1.0, build results are published to artifactory snapshots/path/to/subproject2/4.1.0-snapshot/ and promoted to releases/path/to/subproject2/4.1.0/ +│ ├── subproject2-1 v3.1.0 +│ ├── subproject2-2 v3.2.0 +│ └── subproject2-3 v3.3.0 +├─ brnach v3.x: on v3.2.10, build results are published to artifactory snapshots/path/to/subproject2/3.2.10-snapshot/ and promoted to releases/path/to/subproject2/3.2.10/ +│ ├── subproject2-1 v3.1.0 +│ ├── subproject2-2 v3.2.0 +│ └── subproject2-3 v3.3.0 +└── brnach v4.2-staging: on v4.2.2, build results are published to artifactory snapshots/path/to/subproject2/4.2-staging/ + ├── subproject2-1 v3.1.1 + ├── subproject2-2 v3.2.2 + └── subproject2-3 v3.3.3 +``` + ## Zowe Nightly Builds -Zowe Nightly Builds may contain those less specific versions schemas that the stable release bans. Nightly builds are available for public consumption, but may contain bugs or incomplete features. -The nightly build allows subprojects to gain a head start on their release process, as they can download the nightly build at any time to test their bleeding edge components. If the nightly build is too unstable to be valuable to a subproject, then they should coordinate with the CI/CD team to create a PAX branch off of master. They can use this branch to test their components integration with the Zowe PAX before pushing the latest component to master. \ No newline at end of file +Zowe Nightly Builds may contain those less specific versions schemas that the stable release bans. Nightly builds are available for public consumption, but may contain bugs or incomplete features. Nightly builds are generated from [zowe-install-packaging](https://github.com/zowe/zowe-install-packaging) repository **master** branch. + +The nightly build allows subprojects to gain a head start on their current release process, as they can download the nightly build at any time to test their bleeding edge components. If the new feature is too unstable to be included into current release, then they should coordinate with the CI/CD team to create a **staging** branch off of master. This process is introduced in [Zowe Branches](#zowe-branches) section. They can use this staging branch to test their components integration with the Zowe PAX before pushing the latest component to master. From e1eaa9500b71e7c2c555ae00f194b6d358d76b0e Mon Sep 17 00:00:00 2001 From: Mark Ackert Date: Thu, 1 Nov 2018 10:32:46 -0400 Subject: [PATCH 05/13] Manual testing section Signed-off-by: Mark Ackert --- process/ReleaseProcess.md | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/process/ReleaseProcess.md b/process/ReleaseProcess.md index b1350a5..ea719f7 100644 --- a/process/ReleaseProcess.md +++ b/process/ReleaseProcess.md @@ -1,9 +1,8 @@ # Release Process and Guidelines +## What is a Zowe release -## What is a Zowe release? - -A release of the Zowe project contains two 'convenience' deliverables - CLI binaries, and a PAX file which contains the Zowe API Mediation Layer, Zowe Desktop, and Zowe Explorer-Server. The CLI binaries are obtainable either through standard npm install commands, or, for users with limited internet access, through a convience zip file which allows for offline installation. The CLI convenience zip and Zowe PAX are both available through the official [Zowe Website](https://www.zowe.org). +A release of the Zowe project consists of two 'convenience' deliverables - CLI binaries, and a PAX file which contains the Zowe API Mediation Layer, Zowe Desktop, and Zowe Explorer-Server. The CLI binaries are obtainable either through standard npm install commands, or, for users with limited internet access, through a convience zip file which allows for offline installation. The CLI convenience zip and Zowe PAX are both available through the official [Zowe Website](https://www.zowe.org). Each Zowe release comes with updates to user installation, configuration, and extension documentation. The documentation is developed in the [docs-site repository](https://github.com/zowe/docs-site), is accessible through the [Zowe Website](https://www.zowe.org), and is hosted directly on [Github.io](https://zowe.github.io/docs-site/). @@ -11,7 +10,7 @@ The focus of this document refers to generating stable releases of Zowe. For ble Generating any release of Zowe requires gathering artifacts from each of Zowe's subprojects, organizing them into the Zowe deliverables, testing said Zowe deliverables, signing the deliverables, and publishing the deliverables in sync with Release Notes / Documentation Updates. -## How do we generate a release? +## How to generate a release Stable Zowe releases are generated from [zowe-install-packaging](https://github.com/zowe/zowe-install-packaging) repository **master** branch. The versions defined in [zowe-install-packaging](https://github.com/zowe/zowe-install-packaging) are Zowe official stable version. @@ -34,8 +33,9 @@ In order to generate a new release of Zowe, each of the below checklists must be ### Zowe PAX Checklist -* Build PAX -* Test PAX +* Build PAX through automation +* Test PAX using automation +* Test PAX with any manual tests not covered by automation. See [Leftover Manual Tests](##Manual%20Testing) * Publish as RC candidate * Test RC candidate * Automated smoke tests @@ -140,6 +140,13 @@ For each of the subprojects, may follow similar pattern. But subproject itself m └── subproject2-3 v3.3.3 ``` +## Manual Testing + +| subproject | manual test case | remediation | +|---|---|---| +| zowe-cli | validate version matches intended release | automate either version | +| zowe-cli | validate installation | automate installation of cli + plugins | + ## Zowe Nightly Builds Zowe Nightly Builds may contain those less specific versions schemas that the stable release bans. Nightly builds are available for public consumption, but may contain bugs or incomplete features. Nightly builds are generated from [zowe-install-packaging](https://github.com/zowe/zowe-install-packaging) repository **master** branch. From 5d6e865d4ddbd07ff7156a2f8b2850ec34b30df6 Mon Sep 17 00:00:00 2001 From: Mark Ackert Date: Thu, 1 Nov 2018 10:40:46 -0400 Subject: [PATCH 06/13] add api-layer manual tests Signed-off-by: Mark Ackert --- process/ReleaseProcess.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/process/ReleaseProcess.md b/process/ReleaseProcess.md index ea719f7..5f073e7 100644 --- a/process/ReleaseProcess.md +++ b/process/ReleaseProcess.md @@ -33,14 +33,10 @@ In order to generate a new release of Zowe, each of the below checklists must be ### Zowe PAX Checklist -* Build PAX through automation -* Test PAX using automation +* Build Release Candidate PAX (Automated) +* Test Release Candidate PAX install + smoke (Automated) * Test PAX with any manual tests not covered by automation. See [Leftover Manual Tests](##Manual%20Testing) - * Publish as RC candidate - * Test RC candidate - * Automated smoke tests - * Manual verifications - * Loop if necessary until candidate passes +* IF errors exist within the PAX * Sign the PAX ### Publish Release Checklist @@ -144,8 +140,10 @@ For each of the subprojects, may follow similar pattern. But subproject itself m | subproject | manual test case | remediation | |---|---|---| -| zowe-cli | validate version matches intended release | automate either version | -| zowe-cli | validate installation | automate installation of cli + plugins | +| zowe-cli | validate version matches intended release | present information about bundled CLI versions clearly | +| zowe-cli | validate installation | automate installation of cli + plugins (currently, base CLI install is automated) | +| api-layer | 11 known manual tests | See [Manual Tests](https://github.com/zowe/api-layer/blob/master/docs/manual_tests.md) | + ## Zowe Nightly Builds From 1c275c994c3f7d74e2e02970881b14d6a7237d3f Mon Sep 17 00:00:00 2001 From: Mark Ackert Date: Thu, 1 Nov 2018 10:50:14 -0400 Subject: [PATCH 07/13] update zowe-cli test description Signed-off-by: Mark Ackert --- process/ReleaseProcess.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/ReleaseProcess.md b/process/ReleaseProcess.md index 5f073e7..b69393e 100644 --- a/process/ReleaseProcess.md +++ b/process/ReleaseProcess.md @@ -141,7 +141,7 @@ For each of the subprojects, may follow similar pattern. But subproject itself m | subproject | manual test case | remediation | |---|---|---| | zowe-cli | validate version matches intended release | present information about bundled CLI versions clearly | -| zowe-cli | validate installation | automate installation of cli + plugins (currently, base CLI install is automated) | +| zowe-cli | validate installation follow doc | automate installation of cli + plugins. Follow user guide doc must remain manual. | | api-layer | 11 known manual tests | See [Manual Tests](https://github.com/zowe/api-layer/blob/master/docs/manual_tests.md) | From 9ab91dabfc0440eeedabfbc39935ced6e039b21e Mon Sep 17 00:00:00 2001 From: "Jack (T.) Jia" <39711029+jackjia-ibm@users.noreply.github.com> Date: Thu, 1 Nov 2018 16:16:02 -0400 Subject: [PATCH 08/13] add automated test result link Signed-off-by: Jack (T.) Jia --- process/ReleaseProcess.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/process/ReleaseProcess.md b/process/ReleaseProcess.md index b69393e..499d840 100644 --- a/process/ReleaseProcess.md +++ b/process/ReleaseProcess.md @@ -136,7 +136,15 @@ For each of the subprojects, may follow similar pattern. But subproject itself m └── subproject2-3 v3.3.3 ``` -## Manual Testing +## Automated And Manual Testing + +### Automated Testing + +Each release candidate build will be sanity validated with test cases designed in [zowe-install-test](https://github.com/zowe/zowe-install-test). + +This is the most latest test result: https://projectgiza.org/Automated_Test_Result_HTML_Report/. Please verify and see if there are anything missing. + +### Manual Testing | subproject | manual test case | remediation | |---|---|---| @@ -144,7 +152,6 @@ For each of the subprojects, may follow similar pattern. But subproject itself m | zowe-cli | validate installation follow doc | automate installation of cli + plugins. Follow user guide doc must remain manual. | | api-layer | 11 known manual tests | See [Manual Tests](https://github.com/zowe/api-layer/blob/master/docs/manual_tests.md) | - ## Zowe Nightly Builds Zowe Nightly Builds may contain those less specific versions schemas that the stable release bans. Nightly builds are available for public consumption, but may contain bugs or incomplete features. Nightly builds are generated from [zowe-install-packaging](https://github.com/zowe/zowe-install-packaging) repository **master** branch. From 8e138c40f59dc603276e58b9e18c5bcaf88be056 Mon Sep 17 00:00:00 2001 From: "Jack (T.) Jia" Date: Thu, 15 Nov 2018 10:55:21 -0500 Subject: [PATCH 09/13] update how to find automated test result Signed-off-by: Jack (T.) Jia --- process/ReleaseProcess.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/ReleaseProcess.md b/process/ReleaseProcess.md index 499d840..0ac9ee6 100644 --- a/process/ReleaseProcess.md +++ b/process/ReleaseProcess.md @@ -142,7 +142,7 @@ For each of the subprojects, may follow similar pattern. But subproject itself m Each release candidate build will be sanity validated with test cases designed in [zowe-install-test](https://github.com/zowe/zowe-install-test). -This is the most latest test result: https://projectgiza.org/Automated_Test_Result_HTML_Report/. Please verify and see if there are anything missing. +The most latest test result can be found from Jenkins server pipeline `zowe-install-test` master branch. Also the nightly build test status will be published to [#zowe-build](https://openmainframeproject.slack.com/messages/CC9QW5NJE/) Slack channel. ### Manual Testing From ac953b28a50de6a26729abee135cdf0f6078619d Mon Sep 17 00:00:00 2001 From: Matt Hogstrom Date: Wed, 28 Nov 2018 10:52:10 -0500 Subject: [PATCH 10/13] Updated Release Guidelines to include process, artifacts and minor changes to other aspects of the release process. Signed-off-by: Matt Hogstrom --- process/release.md | 52 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 process/release.md diff --git a/process/release.md b/process/release.md new file mode 100644 index 0000000..f4bc39b --- /dev/null +++ b/process/release.md @@ -0,0 +1,52 @@ +# Zowe Release Process + +## Milestones and Release Candidates +Zowe Milestones are time-base releases that are scheduled on four week intervals. It consists of two week Sprints and a release candidate (RC) that may be made available at the end of the Sprint.  By choosing monthly releases, it greatly simplifies communication and scheduling. With smaller iterations we expect to get feedback quickly. Each Squad will decide if there will be a deliverable depending on the content that went into the Release. Squads are self governing and are free to have their own schedules as long as they meet the requirements of the release as defined by the community. As the project matures, nightly builds should be available for download, but might contain experimental features or bugs. + +## Release Approval Procedure +The ZLC is informed by the Release Manager that a new release is ready for public distribution. The ZLC will review the release and ensure that all requirements that are needed for legal and technical release are met. These include, but are not limited to, updated Documentation, correct LICENSE files, code scans show no known vulnerabilities and some spot testing at the ZLC's discretion. + +The ZLC will create a vote thread on zowe-zlc@lists.openmainframeproject.org to vote for the release. +1 indicates concurrence, 0 is no opinion (and requires a reason to be given) and a -1 is a vote to block the release (rationale required). The vote is to last no more than 1 week but can be completed sooner when all ZLC votes are cast. The results will be communicated to the Release Manager. + +The Release Manager will sign the release with their GPG keys for the Zowe project and the release will be made available. + +Should the vote fail, the ZLC will communicate the issues that caused the release vote to be unsuccessful to the Release Manager who will address those issues and spin a new build. + +## Release Numbering +Each release will be identified by a version number. These numbers are used according to a specific scheme that will give you additional information about the release.  The version numbers are of the form `x.y.z-[GA | beta | yyyymmdd]` (Semantic Versioning) or `major.minor.micro`. The final designation indicates whether this is the official Generally Available (GA) version, a beta version or an interim build. + +- The major version number is increased only when a significant amount of new functionality is added to the previous release. In such cases, the new release version number will be (x+1).0.0. +- The minor version number is increased only when some functionality is added to the new release, in which case the new release version number will be x.(y+1).0. +- When the new release consists mainly of bug fixes, there will be a so-called point release. The version number of the new release in such cases will only have the micro version number increased, resulting in x.y.(z+1). +- **GA** indicates that this release is an official, supported version of the Zowe project and is suitable for regular use. +- **beta** means that this build is a candidate build that is complete but is under active development and should not be considered for regular use. +- **yyyymmdd** indicates this is an interim build suitable for experimentation or development. It is not intended for general usage and may contain defects that are known and being worked or unknown. + +The code can be found [here](https://zowe.org/download/). + +## Release Content +There are two significant and different release artifacts for Zowe. The source release and the "convenience build." + +The project officially release source code which can be built into an executable version of Zowe. This is the core deliverable of Zowe and is intended for downstream consumers that may use Zowe in their projects or products as well as other developers. + +The "Convenience Build" is a courtesy release artifact that includes an installer and all available artifacts to run and use Zowe including sample applications. The convenience build is intended for consumers that simply want to use Zowe and its APIs. This is built from the source code release above. + +## Playbacks +At the end of each Sprint, the Squads will present their work in the form of a Playback that is open to all where they will demonstrate the new capabilities introduced in the Sprint.  + +Calendar invites to the Zowe playbacks will be posted [here](https://lists.openmainframeproject.org/g/zowe-dev/calendar). + +Past Playbacks recordings are available [here](https://github.com/zowe/community/tree/master/Playbacks/Meeting%20Minutes%20and%20Recordings). + +## Meetings +The various squads and Zowe Leadership Committee (ZLC) meet on a weekly basis. The squad schedules can be found [here](https://github.com/zowe/release-management/wiki/Meeting-Schedule) along with the meeting recordings and minutes. + +## Communication Channels +The Zowe projects have three communication channels: a mailing list, a Slack channel, and a Waffle Board. +Ypu can find more details about each communication channel on the Zowe website [here](https://zowe.org/contribute). + +## Conference Calls +All the conference calls are set up using Zoom. Each squad provides the details and call-in information in the invitation. To get an invitation, you must register on the Open Mainframe Project Group called "zowe-dev@lists.openmainframeproject.org" group at https://lists.openmainframeproject.org/g/zowe-dev + +## Post Release Activities +Once it has been decided to ship a release, the Zowe Build team publishes the deliverable along with all documentation. \ No newline at end of file From 360c87c117099cbaedca7453c78508b6d90b0d7f Mon Sep 17 00:00:00 2001 From: Matt Hogstrom Date: Wed, 16 Jan 2019 08:44:23 -0500 Subject: [PATCH 11/13] Agenda for January 16, 2019 Meeting --- meetings/2019-01-16/Agenda.md | 65 +++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 meetings/2019-01-16/Agenda.md diff --git a/meetings/2019-01-16/Agenda.md b/meetings/2019-01-16/Agenda.md new file mode 100644 index 0000000..56b9e8a --- /dev/null +++ b/meetings/2019-01-16/Agenda.md @@ -0,0 +1,65 @@ +__2019-01-16__ + +**ZLC Members** +[ ] Matt Hogstrom +[ ] Bruce Armstrong +[ ] Jean-Philipe +[ ] Sean Grady +[ ] Mark Ackert +[ ] Jean-Louis + +**Participants** +[ ] Joe Winchester +[ ] Tim Brooks +[ ] Alvin Tan +[ ] Nick Kocsis +[ ] Paul Bartholf +[ ] Macgr04 +[ ] Steven Horsman + +## Recording can be found here: + +## Issues to be discussed on 2019-01-16 +1.0 Release Update +- ZSS +- Message IDs OMP and ZWE reserved from IBM +- RACF Class ZOWE and Posit 607 reserved by IBM +- ECVT Allocated - 4-byte slot 144 in the area pointed to by ECVTCTBL (the 4 bytes at offset x'23C') to the OMP. +- Pending install of Metal C on River +- Explorer Update +- When will we start dropping nightly builds for 1.0 for widespread testing (including ZSS) +- Installation changes + +All, review 1.0 Goals and ensure the document accurately reflects project goals. +1.0 Discussion and outstanding issues + +Release Documents in release branch - are we ready to vote? +Action: Asked all members to review in prep for 1.0 release. + +[Signing of Interim builds](https://github.com/zowe/zlc/issues/68) + + +### Updates + +[Zowe GA 1.0.0 Goals](https://github.com/zowe/zlc/issues/37) + - Added Tim Brooks and asked him to update this issue with the 1.0 items that have been discussed. + - Proposal to release 1.0 in January (last Tuesday) to allow more time for integration, performance and testing. + +[Zowe Conformance Program](https://github.com/zowe/zlc/issues/52) - +Meeting held on 2018/11/26 to discuss conformance. @Tbr00sky drafting initial set of capability. + +[Review @brightside usages for GA to do](https://github.com/zowe/zlc/issues/28) - Update from John on progress + 1. Mandate if the work needs to be completed + 2. If (1) passes vote, then declare a timeframe for completion. 1.0.0 or can it be pushed after 1.0.0? + 3. CA Technologies still owns the trademark on Brightside. + Next step: John to engage LF legal and then work with contributoer legal departments to get consensus. Update at next ZLC 12-5-2018 + +### Actions + +### Post 1.0 Activities +[Process - Project Planning (PI Planning)](https://github.com/zowe/zlc/issues/40) +[Open Source Development Metrics](https://github.com/zowe/zlc/issues/3) + +### Closed Issues +[Achieve CII Best Practices badge in progress](https://github.com/zowe/zlc/issues/38) +Complete ... Thanks to all who got us over the finish line. From f5814209909e4aa1e28dcc89c3c263649735e9fd Mon Sep 17 00:00:00 2001 From: Matt Hogstrom Date: Wed, 16 Jan 2019 15:17:29 -0500 Subject: [PATCH 12/13] Updated with notes and comments from meeting Signed-off-by: Matt Hogstrom --- meetings/2019-01-16/Agenda.md | 40 +++++++++++++++++++++++++---------- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/meetings/2019-01-16/Agenda.md b/meetings/2019-01-16/Agenda.md index 56b9e8a..f0b6af4 100644 --- a/meetings/2019-01-16/Agenda.md +++ b/meetings/2019-01-16/Agenda.md @@ -1,38 +1,56 @@ __2019-01-16__ **ZLC Members** -[ ] Matt Hogstrom -[ ] Bruce Armstrong -[ ] Jean-Philipe +[X] Matt Hogstrom +[X] Bruce Armstrong +[X] Jean-Philipe [ ] Sean Grady -[ ] Mark Ackert -[ ] Jean-Louis +[X] Mark Ackert +[X] Jean-Louis **Participants** -[ ] Joe Winchester -[ ] Tim Brooks -[ ] Alvin Tan +[X] John Mertic +[X] Greg McKinnon +[X] Joe Winchester +[X] Tim Brooks +[X] Alvin Tan [ ] Nick Kocsis -[ ] Paul Bartholf -[ ] Macgr04 +[X] Paul Bartholf +[X] Macgr04 +[X] Mike Maliska [ ] Steven Horsman +[X] Petr ## Recording can be found here: +https://zoom.us/recording/share/-IRHQne14KEtDy4P9K1VmJAhYeSoRZ3PajMfdxP5erKwIumekTziMw?startTime=1547646890000 + ## Issues to be discussed on 2019-01-16 1.0 Release Update - ZSS - Message IDs OMP and ZWE reserved from IBM - RACF Class ZOWE and Posit 607 reserved by IBM - ECVT Allocated - 4-byte slot 144 in the area pointed to by ECVTCTBL (the 4 bytes at offset x'23C') to the OMP. +- (Update info@openmainframeproject.org as the registration point for these resources) - Pending install of Metal C on River - Explorer Update -- When will we start dropping nightly builds for 1.0 for widespread testing (including ZSS) + - Liberty is removed. USS and JES are functional. MVS is pending. An extra week is requested. +- When will we start dropping nightly builds for 1.0 for widespread testing (including ZSS). nightly builds are available ... no release candidates yet. +- APIML - SSO integration with the Desktop ... currently can be disabled. Explorer will not be ready for SSO exploitation. +- Scan Results (3 areas that need to be addressed. + - Delivering binaries from third parties. Better documentation for binary jars. ) + - React jars to move to newer jars to avoid older license. + - Other licenses that may not be compatible. + - # Need a license waiver - Installation changes + - Add ZSS (xmem server) All, review 1.0 Goals and ensure the document accurately reflects project goals. 1.0 Discussion and outstanding issues +Release Dates +- February 5th, 2019 is target 1.0 GA (verbal agreement by ZLC members present.) + Release Documents in release branch - are we ready to vote? Action: Asked all members to review in prep for 1.0 release. From 8acec2c9051fc249356e5f748b9d60876bed9fcb Mon Sep 17 00:00:00 2001 From: Matt Hogstrom Date: Wed, 16 Jan 2019 15:17:29 -0500 Subject: [PATCH 13/13] Updated with notes and comments from meeting Signed-off-by: Matt Hogstrom --- meetings/2019-01-16/Agenda.md | 40 +++++++++++++++++++++++++---------- 1 file changed, 29 insertions(+), 11 deletions(-) diff --git a/meetings/2019-01-16/Agenda.md b/meetings/2019-01-16/Agenda.md index 56b9e8a..f0b6af4 100644 --- a/meetings/2019-01-16/Agenda.md +++ b/meetings/2019-01-16/Agenda.md @@ -1,38 +1,56 @@ __2019-01-16__ **ZLC Members** -[ ] Matt Hogstrom -[ ] Bruce Armstrong -[ ] Jean-Philipe +[X] Matt Hogstrom +[X] Bruce Armstrong +[X] Jean-Philipe [ ] Sean Grady -[ ] Mark Ackert -[ ] Jean-Louis +[X] Mark Ackert +[X] Jean-Louis **Participants** -[ ] Joe Winchester -[ ] Tim Brooks -[ ] Alvin Tan +[X] John Mertic +[X] Greg McKinnon +[X] Joe Winchester +[X] Tim Brooks +[X] Alvin Tan [ ] Nick Kocsis -[ ] Paul Bartholf -[ ] Macgr04 +[X] Paul Bartholf +[X] Macgr04 +[X] Mike Maliska [ ] Steven Horsman +[X] Petr ## Recording can be found here: +https://zoom.us/recording/share/-IRHQne14KEtDy4P9K1VmJAhYeSoRZ3PajMfdxP5erKwIumekTziMw?startTime=1547646890000 + ## Issues to be discussed on 2019-01-16 1.0 Release Update - ZSS - Message IDs OMP and ZWE reserved from IBM - RACF Class ZOWE and Posit 607 reserved by IBM - ECVT Allocated - 4-byte slot 144 in the area pointed to by ECVTCTBL (the 4 bytes at offset x'23C') to the OMP. +- (Update info@openmainframeproject.org as the registration point for these resources) - Pending install of Metal C on River - Explorer Update -- When will we start dropping nightly builds for 1.0 for widespread testing (including ZSS) + - Liberty is removed. USS and JES are functional. MVS is pending. An extra week is requested. +- When will we start dropping nightly builds for 1.0 for widespread testing (including ZSS). nightly builds are available ... no release candidates yet. +- APIML - SSO integration with the Desktop ... currently can be disabled. Explorer will not be ready for SSO exploitation. +- Scan Results (3 areas that need to be addressed. + - Delivering binaries from third parties. Better documentation for binary jars. ) + - React jars to move to newer jars to avoid older license. + - Other licenses that may not be compatible. + - # Need a license waiver - Installation changes + - Add ZSS (xmem server) All, review 1.0 Goals and ensure the document accurately reflects project goals. 1.0 Discussion and outstanding issues +Release Dates +- February 5th, 2019 is target 1.0 GA (verbal agreement by ZLC members present.) + Release Documents in release branch - are we ready to vote? Action: Asked all members to review in prep for 1.0 release.