-
Notifications
You must be signed in to change notification settings - Fork 14
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'master' into messageManagement
- Loading branch information
Showing
6 changed files
with
352 additions
and
5 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,83 @@ | ||
| __2019-01-16__ | ||
|
|
||
| **ZLC Members** | ||
| [X] Matt Hogstrom | ||
| [X] Bruce Armstrong | ||
| [X] Jean-Philipe | ||
| [ ] Sean Grady | ||
| [X] Mark Ackert | ||
| [X] Jean-Louis | ||
|
|
||
| **Participants** | ||
| [X] John Mertic | ||
| [X] Greg McKinnon | ||
| [X] Joe Winchester | ||
| [X] Tim Brooks | ||
| [X] Alvin Tan | ||
| [ ] Nick Kocsis | ||
| [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 | ||
| - 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. | ||
|
|
||
| [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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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 | | ||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,159 @@ | ||
| # Release Process and Guidelines | ||
|
|
||
| ## What is a Zowe release | ||
|
|
||
| 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/). | ||
|
|
||
| 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 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. | ||
|
|
||
| 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-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-release-notes) | ||
|
|
||
| ### 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 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) | ||
| * IF errors exist within the PAX | ||
| * Sign the PAX | ||
|
|
||
| ### Publish Release Checklist | ||
|
|
||
| * 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, 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) 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 | ||
| ``` | ||
|
|
||
| ## 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). | ||
|
|
||
| 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 | ||
|
|
||
| | subproject | manual test case | remediation | | ||
| |---|---|---| | ||
| | zowe-cli | validate version matches intended release | present information about bundled CLI versions clearly | | ||
| | 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. | ||
|
|
||
| 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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.