<style> table, th, td { border: 1px solid black; padding: 4px; } .faq-hide { display: none; } .bluebackground.conformance-criteria h5, .bluebackground.conformance-criteria .card-text, .bluebackground.conformance-criteria .card-body { color: #145391; } p .card-black { color: black; } </style>
Latest Announcements
General Information
Coming changes to the functionality
Changes to the Conformance Criteria
Office Hours
Frequently Asked Questions
Starting from 12/08, the Zowe Onboarding Squad will hold the Office Hours to discuss the details about the upcoming V2 release. More information can be found in the Office Hour section.
If you want to learn more about what you can expect compatibility wise, the statement is here
Breaking changes for Zowe CLI end users
zowe configno longer manages app settings (Imperative & CLI)fail-on-errordefault changed to true forzowe plugins validate(Imperative & CLI)- Default Imperative and CLI log level changed from DEBUG to WARN (Imperative & CLI), which potentially changes troubleshooting steps for providing information to support.
Breaking changes that could prevent a V1 plug-in (or SDK) from working in V2
- CLI package should be removed as a plug-in peer dep (Imperative)
AbstractRestClient.mDecodedefaults to true so any plugin with custom RestClient implementation that adds gzip decompression may break- Any command with
--dcdwill not behave the way you expect it to (undocumented global option for Daemon Mode Current Directory - to be mentioned in updated conformance criteria) The return value for PluginManagementFacility.requirePluginModuleCallbackchanged.
Context:
Application (and Plugin) developers requiring a module from a plug-in’s relative path using the requirePluginModuleCallback function no longer need to provide the plug-in name in a separate variable this.pluginNmForUseInCallback = pluginName
before binding the classthis.requirePluginModuleCallback.bind(this).
Instead they can callthis.requirePluginModuleCallback(pluginName).Common usage: ConfigurationLoader.load
Before:
this.pluginNmForUseInCallback = pluginName
ConfigurationLoader.load(null,pkgJsonData,this.requirePluginModuleCallback.bind(this))After:
pluginConfig = ConfigurationLoader.load(null,pkgJsonData,this.requirePluginModuleCallback(pluginName))
The following changes were marked for deprecation in the zowe-v1-lts release. These changes are also less likely to impact plug-ins.
- AbstractRestClient.performRest → AbstractRestClient.request
- AbstractSession.HTTP_PROTOCOL → SessConstants.HTTP_Protocol
- AbstractSession.HTTPS_PROTOCOL → SessConstants.HTTPS_Protocol
- AbstractSession.TYPE_NONE → SessConstants.AUTH_TYPE_NONE
- AbstractSession.TYPE_BASIC → SessConstants.AUTH_TYPE_BASIC
- AbstractSession.TYPE_BEARER → SessConstants.AUTH_TYPE_BEARER
- AbstractSession.TYPE_TOKEN → SessConstants.AUTH_TYPE_TOKEN
- ICliLoadProfile.ICliILoadProfile → ICliLoadProfile.ICliLoadProfile
- IImperativeErrorParms.suppressReport → removed
- IImperativeConfig.pluginBaseCliVersion → removed
- CliUtils.promptForInput → CliUtils.readPrompt
- CliUtils.promptWithTimeout → CliUtils.readPrompt
- (zosmf) IZosfmMessages → IZosmfMessages
- (workflows) listWorkflows → getWorkflows
- (workflows) getResourcesQuery → getResourceQuery
- (workflows) archiveWorfklowByKey → archiveWorkflowByKey
- (uss) createBasicSshSession → createSshSessCfgFromArgs
- (uss) createBasicSshSessionFromArguments → createSshSessCfgFromArgs
- (zosmf) createBasicZosmfSession → createSessCfgFromArgs
- (zosmf) createBasicZosmfSessionFromArguments → createSessCfgFromArgs
- (files) bufferToUSSFile → bufferToUssFile
- (files) streamToUSSFile → streamToUssFile
- (files) fileToUSSFile → fileToUssFile
Breaking changes for Zowe CLI & Imperative plug-in developers (V2-V2 - these changes only impacted early adopters of @next as these are breaking changes made during the technical preview validation phase - thanks to the community for their feedback)
tokenTypeandtokenValuewere combined intoauthTokenand we later reverted this change (Imperative & CLI)- Options in
zowe configgroup renamed:--user→--user-configand--global→--global-config - Zowe.schema.json format changed a few times (version 2, version 3):
ConfigSchemas.loadProfileSchemas→ConfigSchemas.loadSchemaConfig.set no longer coerces string values to other types unless parseString = true (potential SDK impact - not CLI Plug-in impact)
- Changes to settings keys - automated migration of settings when user opens Zowe Explorer v2: (includes documentation) (#PR 1450)
- Using Global Profiel Configuration
- Changes Affecting Extenders
Summary: Major install & configuration simplication due to various improvements. Reduced overhead and increased performance due to reduction in server count, optimised networking, and 64 bit ZSS
- Consolidation of Web Explorer Servers: Explorer USS, MVS, and JES no longer have node servers (3 less servers), due to utilizing app-server for hosting.Consolidation of web explorer servers
- Jobs & Datasets APIs now disabled by default (2 less servers), and Explorers do not rely on them
- Replace referrer security check with 'samesite' cookie option: No longer need to specify external hostname to pass security check
- Remove "loopback routing" in app-server: Resolves bugs around use of a loopback IP when running app-server
- Can specify advanced app-server & zss config in zowe.yaml: Simplify/Unify app framework configuration by using 1 config file rather than 2 (instance.env, server.json)
- Contiguous default ports: App framework ports (formerly 85xx) now follow APIML ports (75xx)
- App-server bind to IP_ADDRESS by default: Instead of '0.0.0.0', app-server now uses same IP as rest of Zowe servers
- Consistent environment variable names: Standardize environment variable names around ZWED_, and ZWES_ prefixes for consistency. Aliases to previous names
- Informative desktop login messages: Desktop login failures now print useful troubleshooting details about server communication issues
- ZSS 64 bit: ZSS 64 bit version now exists alongside prior 31-bit version. Better performance and higher memory limit. Now utilizes 64-bit cross-memory to ZIS
- New desktop library versions: Angular 6->12, Corejs 2->3, Typescript 2->4
Some configuration, such as port and IP values, are different by default but can be reconfigured to old values. But, some app framework extensions may not work in v2 without enhancements.
- Consolidation of Web Explorer Servers: Bookmarks to USS, MVS, JES explorers will be broken, due to URL change
- "loopback routing" disabled: Loopback routing alternative may not be 100% compatible, can be disabled via config parameter node.internalRouting=false
- Server.json removed: The now-mandatory zowe.yaml can contain the same content as server.json, within the objects components.app-server and components.zss
- Scripts that wrote to
server.jsonwill be broken, adapt them to write tozowe.yamlinstead - Incompatible desktop library version upgrades: Angular 12, corejs, and typescript were updated in the Desktop, and non-iframe plugins that depend on them may break
- ZSS cookie name change: ZSS cookie name now includes a suffix of either port name or HA/FT ID to distinguish between unrelated ZSS servers
All the changes are available here: Box Excel Sheet
| Item Number | Original Version | New version |
| 6 | The API ID must follow the same rules for Java packages. Example of the API ID: zowe.apiml.apicatalog | Services must provide API ID to allow for Automated CLI Client Configuration. |
| 8 | For versioned and non-versioned APIs, service URLs must contain a service version before the service ID (all formats) | For versioned and non-versioned APIs, service URLs must contain a service ID in the first place in the path, before the service version (all formats) |
|
Item
|
V
|
Req
|
Best Practice
|
V
|
Req
|
Best Practice
|
Conformant
|
Conformance Criteria | Notes | ||
| Infrastructure | |||||||||||
| 1 | v2 | x | v1 | x | Plug-in is constructed on the Imperative CLI Framework | ||||||
| 2 | v2 | x | v1 | x | Plug-in is NOT run as a standalone CLI | ||||||
| 3 | v2 | x | v1 | x | Plug-in commands write to stdout or stderr via Imperative Framework response.console APIs | ||||||
| 4 | v2 | x | If plug-in requires gzip decompression support, leverage the Core CLI built-in support -- do NOT opt-out of the built-in gzip decompression support (specifically, the `mDecode` property of the Imperative RestClient must NOT be overridden). | ||||||||
| 5 | v2 | x | Plug-ins must not have an @zowe/cli peer dependency for improved npm@7 compatibility. The only peer dependencies that should be included are packages which are imported in the plug-in's source code (e.g., @zowe/imperative). | ||||||||
| 6 | v2 | x | In their Imperative config file (defined in the imperative.configurationModule property of package.json), plug-ins should make their imports as few and specific as possible. This can significantly decrease their load time (example). | ||||||||
| 7 | v2 | x | HTTP or HTTPS requests to REST APIs should use the @zowe/imperative RestClient instead of a direct dependency on a 3rd-party package like request or axios. | ||||||||
| Installation | |||||||||||
| 8 | v2 | x | v1 | x | Plug-in is installable with the zowe plugins install command | ||||||
| 9 | v1 | x | Plug-in is installable into the @zowe-v1-lts version of the core Zowe CLI and follows semantic versioning | ||||||||
| 10 | v2 | x | Plug-in is installable into the @zowe-vN-lts version of the core Zowe CLI and follows semantic versioning (where "N" = the latest "active" LTS release number) | ||||||||
| 11 | v2 | x | v1 | x | Plug-in is uninstallable via the zowe plugins uninstall command | ||||||
| 12 | v2 | x | `@latest` should point to the same version as the most recent zowe lts tag (Note: for V2 it will be `@zowe-v2-lts`) | This will give users options: They can (1) install explicitly from the "N" release using`@zowe-vN-lts` so that they remain on "N" when `@zowe-vN+1-lts` becomes available OR (2) install from `@latest` and automatically accept new major LTS versions as they are released. Note: @latest is the default chosen when a user installs without specifying a tag -- `@next` is used for validating early access features planned for the next major release | |||||||
| Naming | |||||||||||
| 13 | v2 | x | v1 | x | If the plug-in introduces a command group name, it does not conflict with existing conformant plug-in group names | ||||||
| 14 | v2 | x | Names of CLI commands/groups/options must be in kebab case (lower case & hyphens). Names of properties in zowe.config.json should be camel case. Only alphanumeric characters should be used - `[a-zA-Z0-9-]+`. | ||||||||
| 15 | v2 | x | The following option names/aliases are reserved and must not be used: --dcd, --response-format-json, --rfj, --help, -h, --help-examples, --help-web, --hw | ||||||||
| Profiles | |||||||||||
| 16 | v2 | x | v1 | x | If the plug-in has unique connection details, it introduces a profile that lets users store these details for repeated use | ||||||
| 17 | v2 | x | v1 | x | Plug-in users are able to override all profile settings via the command line and/or environment variables | ||||||
| 18 | v2 | x | If the plug-in uses a Zowe API-ML integrated API, it (the plug-in) has an option named `base-path` in the profile to used to house the path of the associated service in the API ML. | ||||||||
| 19 | v2 | x | If the plug-in connects to a service, it must include the following profile properties AND they MUST be these exact properties (e.g. host, NOT hostname): 'host', 'port', 'user', 'password' | ||||||||
| 20 | v2 | x | If the plug-in connects to a service, and the service supports logging in with a token, it must include the following profile properties AND they MUST be these exact properties: 'tokenType', 'tokenValue' | ||||||||
| 21 | v2 | x | If the plug-in connects to a service, and the service supports logging in with PEM certificates, it must include the following profile properties AND they MUST be these exact properties: 'certFile', 'certKeyFile' | ||||||||
| 22 | v2 | x | If the plug-in connects to a service, and the service supports logging in with PFX/P12 certificates, it must include the following profile properties AND they MUST be these exact properties: 'certFile', 'certFilePassphrase' | ||||||||
| 23 | v2 | x | If the plug-in provides an option to reject untrusted certificates, the property must be named “rejectUnauthorized”. CLI option should be reject-unauthorized. | ||||||||
| 24 | v2 | x | The plug-in specifies options to be pre-filled by default in zowe.config.json once `zowe config init` has executed | ||||||||
| 25 | v2 | x | Plug-in supports team-profile config | Should work if other conformance criteria are met. | |||||||
| 26 | v2 | x | Plug-in supports base profiles | ||||||||
| 27 | v2 | x | When host, port, user, or password is missing for a particular command and no default value is set, the user is prompted for the argument. Host, user, and password should NOT have default values. | Call
ConnectionPropsForSessCfg.addPropsOrPrompt before instantiating Session object See Medium blog |
|||||||
| 28 | v2 | x | To take advantage of the new 'zowe config auto-init' command, a plugin that works with a single-sign-on, APIML-compliant REST service MUST supply a new object within its plugin definition to identify that REST service. The new IImperative.apimlConnLookup object must be in the plugin's definition. That object includes the apiId and gatewayUrl of the corresponding REST service. The related REST service must also supply its apiId and gatewayUrl in the apiml section of its application.yml definition. Zowe-CLI automatically handles the apimlConnLookup object for the 'zosmf' service. Thus an apimlConnLookup object for 'zosmf' does not have to be specified within a plugin. | ||||||||
| Support | |||||||||||
| 29 | v2 | x | v1 | x | Submitter describes how Support is provided and Support details are clearly documented | ||||||
| Documentation | |||||||||||
| 30 | v2 | x | Plug-in command help is contributed to this repo for the purpose of hosting the ecosystem web-help on Zowe Docs - https://github.com/zowe/zowe-cli-web-help-generator |
Check out the OMP Calendar for specific time of the V2 office hours.
| Date | Topic | Link to the meeting | Link to the recording | Links to the materials |
| 12/08/2021 12PM - 1PM ET | Kickoff | https://zoom.us/j/94312528890 | Zoom recording | Presentation |
| 01/05/2022 12PM - 1PM ET | CLI | https://zoom.us/j/94312528890 | ||
| 01/12/2022 12PM - 1PM ET | API Mediation Layer | https://zoom.us/j/94312528890 | ||
| 01/19/2022 12PM - 1PM ET | Explorers | https://zoom.us/j/94312528890 | ||
| 01/26/2022 12PM - 1PM ET | Web UI (Zowe Application Framework) | https://zoom.us/j/94312528890 | ||
| 02/02/2022 12PM - 1PM ET | Systems / Install | https://zoom.us/j/94312528890 | ||
| 02/09/2022 12PM - 1PM ET | *Optional:* General Information | https://zoom.us/j/94312528890 | ||
| 02/16/2022 12PM - 1PM ET | *Optional:* General Information | https://zoom.us/j/94312528890 | ||
| 02/23/2022 12PM - 1PM ET | General Wrap-up | https://zoom.us/j/94312528890 |
1. What is the “official” date of Zowe V2 LTS?
The official date is TBD, the target is Feb 28, 2022; look for the official announcement at Zowe.org landing page announcement banner.
2. Where can I find the current (V1) and new (V2) LTS conformance criteria?
The Zowe Squads have prepared XLS spreadsheets with conformance criteria for all Zowe extensions including: CLI, APIs, App Framework, and Explorerfor VS Code. The spreadsheets clearly show the prior / V1 criteria alongside the new / V2 criteria. Please be aware, there are additions, deletions, and CHANGES to the criteria. In some cases the change is simply that a BEST PRACTICE has been deemed REQUIRED. Use the light-GREEN highlights to easily identify the changes. See the Changes to the Conformance Criteria section at Zowe.org/vNext.
3. Will my V1 conformant extension automatically work with V2?
NO. We recommend testing all V1 conformant extensions. See the Coming changes (For Users) section at Zowe.org/vNext.
4. What if my extension does not work with Zowe V2?
See the recommendations in the Coming changes (For Users) section at Zowe.org/vNext.
5. How can I test my current plug-in and/or extension with Zowe V2?
Obtain the pre-GA Zowe V2 release; for details see the pre-GA DOWNLOAD section at Zowe.org/vNext.
6. Do I need to reapply for conformance?
YES, we expect the Zowe V2 Conformance program to be available in early Feb 2022. We will announce when extenders can pre-apply in the LATEST ANNOUNCEMENTS section at Zowe.org/vNext.
7. What happens to my V1 conformance badge?
All Zowe V1 conformance badges will remain at the Open Mainframe Project Interactive Landscape; we recommend documenting a Zowe compatibility matrix to ensure clients are aware of any/all compatibility issues between your V1 conformant apps and Zowe V2.
8. Will I be able to pre-apply for Zowe V2 conformance?
Yes, We will announce when extenders can pre-apply in the LATEST ANNOUNCEMENTS section at Zowe.org/vNext.
9. When can I share this information with my customers?
Anytime. Zowe is an open source project managed by a transparent, open source community.
10. How long will V1 LTS be supported?
The V1 LTS Maintenance timeline runs through July 2024. See RELEASE TIMELINE at Zowe.org/download.
11. What if my extension does not qualify for V2 conformance?
You have several options:
- Notify your customer base and advise them to remain on Zowe V1 LTS until you are able to make the necessary modifications to satisfy all of the new requirements (Note: extenders can choose NOT to be “day-1” V2 conformant )
- Notify your customer base of V2 compatibility concerns (or lack thereof) and advise accordingly (e.g. extension operates but will not leverage V2 features etc.)
- Replace your extension with a V2 conformant extension and indicate it as such
12. Where can I go for more information or get interactive help? (my question is not listed here)
You have several options:
- Attend one (or more) of the (7) bi-weekly Zowe V2 OFFICE HOURS meetings offered on Wednesdays at 12pm ET. Kickoff is scheduled for 12/8. Following (6) meetings are scheduled for: 1/05, 1/12, 1/19, 1/26, 2/2, 2/23 There are 2 more optional meetings plannes for 2/9, 2/16
- Interact with a Zowe Community Member via SLACK. Click on the COMMUNITY tab at Zowe.org, navigate to the SLACK box and click #zowe-onboarding
- Join a Zowe Squad call. Click on the COMMUNITY tab at zowe.org, navigate to the JOIN A SQUAD CALL section on this page. Click on one of the calendar entries for Zoom meeting links.
13. Will the Zowe V2 Office Hours be recorded? (How do I find the recording?)
Yes. Recordings can be provided on request. Click on the COMMUNITY tab at Zowe.org, navigate to the SLACK box and click #zowe-onboarding and request the recording.
14. Will there be a means to migrate (or convert?) existing / old-style profiles to the V2 team config for Zowe CLI? Will it handle profiles that are secured by SCS?
Yes, we plan to introduce a "zowe config convert-profiles" command, which will be available in the v2 release.
15. Will (CLI)Daemon mode be integrated seamlessly into v2 and enabled by default?
This work is still in progress-we are working on a "zowe daemon enable" command to make the daemon installation process as seamless as possible. Daemon mode will be disabled by default, the command must be run to enable it.
16. The V1 version of Zowe Explorer offers a text input area, where a user can enter some of the data / attributes (host, port, etc.) necessary to create the old-style profiles. With Team Config what options are available for users to edit the config file? Is it manual? Is there a UI?
The recommended approach for editing the config file is to launch it in VS Code from Zowe Explorer and make modifications there. The designated user responsible for creating and maintaining the config (we recommend a team lead or Administrator) will be able to leverage the built-in “intellisense” when editing the file. Note: Team Config fundamentally changes the paradigm on profile creation & management. Prior to Team Config, all users were required to understand, create, test, trouble-shoot, and manage their own profiles. Team Config was designed to scale all of these tasks back, remove the burden from individual users and centralize it. Once the config is distributed most users should not need to make any significant edits.
Join the discussion on this topic here: zowe/zowe-explorer-vscode#1535