Zowe Long Term Support Plan

[MarkAckert]

As part of post-1.0.0 activities, we need to discuss how to support teams which have breaking changes in their near term development timeline. The term 'breaking' specifically refers to changes which would violate backwards compatibility within any public-facing API.

One suggestion:

• Given Zowe 1.x is generally available...
• New non-breaking code and maintenance flow into the 1.x PAX. We maintain nightly builds for 1.x, as well as incremental releases around sprint boundaries.
• All new code and maintenance, including breaking changes, flow into a 2.x PAX. This PAX is nightly-only until the community transitions from 1.x to 2.x. The ZLC should help or control the transition point from 1.x to 2.x as the 'currently supported' release. Once ZLC approves transition, 2.x begins incrementally releases on sprint boundaries, 3.x is created as nightly-only, and 1.x is sunset.

[hogstrom]

In general Z customers don't expect APIs to break their code but rather for changes to not break clients but they could introduce new function. I know its not open source or agile but no one wants the code they write to break a year later ...

What kind of breakage are we talking about ? Sample ? Is there a conversation in Slack with examples ?

[MarkAckert]

The sample breakage brought up in discussion was the CLI changing a parameter name - e.g. from "--password" to "--pass" (the example was not this specific field, I can't remember which one was brought up). This would break any scripted environments using the CLI in a CI/CD pipeline.

Ideally in most cases we should modify APIs by extending them, and we should version API interfaces to protect clients from breakage (e.g. REST APIs /v1/functionA vs /v2/functionA ). The goal of this discussion is to have a plan for when we cannot adhere to those guidelines and must break some API - how does the larger Zowe deliverable handle it in terms of versioning/release & transparency/documentation.

[Joe-Winchester]

CLI already has aliases for quite a few parms, e.g. "data-sets" can be shortened to "ds' or "local-files" to "ls" and both arguments work. Would it be possible to provide support for both the long and the short version of password ? I agree with @hogstrom and others that we should do all we can to not introduce API breaking changes mid version as a precedent

[hogstrom]

In this instance, I would continue to support both and put out a deprecation warning. Something like:

The usage of command line parameter --password is being deprecated and will be removed in 2.0. Please use --pass instead.

The consequence is that doing that would require the enduser to modify every one of their scripts prior to 2.0. A lot of busy work that doesn't make their life any easier and adds to their todo list. Worst case, causes service disruptions because people ignored the message. In the end, diminishes the value of project making minor changes like that.

Assuming that we take an N-2 approach on API deprecation (for instance, in this case assuming it is --password in 1.0 and would no longer work in 4.0 but would be tolerated in 2.0 and 3.0) I think the negative impression could be avoided.

For those in the Z world, they still run code that was written 30 years ago with no required updates and its a platform value proposition.

Net, I'd say inform of deprecation and support N-2 as a best practice.

[MarkAckert]

I agree with this approach. Can we request the squad leads review this and confirm their API status and intended compliance with deprecation / N-2 approach?

[hogstrom]

Needs a formal proposal for development guidance for projects to sync on for support.

Sean's input is to use time instead of versions to decouple from community release velocity.

@armstro @MarkAckert

[hogstrom]

@armstro bruce to propose a document with the plan. Review next week

[armstro]

Proposal is for squad leads and ZLC to identify a release within the last 2 weeks of 3Q of each year worthy of being designated a Long Term Support Release (LTSR). The release would be declared a LTSR candidate for 30 days and request consumers of the release to do any additional testing of the LTSR candidate. After the 30 day candidate period and with input from the squad leads and any other contributors, the ZLC will vote to designate the release a LTSR. (Note: The LTSR may or may not be on a version boundary. The LTSR can be the last release of a version or a release within a version.)

Once designated a LTSR, the source code tree (and convenience build and the build process) would be supported by the open community for a period of 2 years from the date of the LTSR approval vote. The source code and executable would be updated for only fixes during the 2 year period at the discretion of the committers. The intent of the LTSR is to allow consumers of the code a 2 year stable window of time for use in customer environment and therefore not to be frequently updated. Fixes would only be provided for defects impacting a production environment with no viable work around or in the event of a security exposure identified after the 30 day testing period of the LTSR candidate.

The source code tree of a LTSR is to remain on the OMP Zowe site indefinitely for use by anyone with committer status. (The build scripts used at the time would also be provided but not guarantee of a build environment after the 2 year LTSR support period).

Example node.js support https://nodejs.org/en/about/releases/

[armstro]

@jlvignaudCA @jplinardon sorry if you see this twice - I want to confirm you see my proposal for you to have time to consider it before ZLC tomorrow - net of the proposal is a LTSR designated once a year to be supported by the open community for 2 years. Source code available for 5 years for anyone to use as they see fit (i.e., like a fee based support offering) BUT no guarantee of a build environment after the 2 year support window.

Question for @MarkAckert and @jackjia-ibm on the feasibility of supporting yearly LTSR and the build process for 2 years.

@alvin-tan @Tbr00ksy FYI

[jplinardon]

I think the fundamentals are good. Are there any consideration or explicit guarantees in regards to migration between LTSR versions?

[armstro]

@jplinardon To me (open to debate) the migration effort is between versions of Zowe and not necessarily related to LTSR. Release to release "should" have backward compatibility. Moving to a new version might have migration considerations. (Even moving between versions we need to minimize any migration pain but a new version will be a boundary that allows properly documented "breaking changes".) I think the last release of a version will generally be a LTSR. But I think there can be a LTSR that is not a different version with migration considerations.

There will come a time when we need to move from V1 to V2. Part of the reason I say the LTSR candidate is decided by squad leads and ZLC is to help decide when to make a LTSR and the specific verionsing/numbering scheme not be set in stone. I propose the last release of version 1 be the LTSR before we shift to a V2. So it might be V1.10.x (or whatever the middle digit is at the time of the decision). Since we have some anticipated "breaking changes" (i.e., NPM naming impacting CLI install scripts) on the horizon that cause us to move to a V2. We will need to get a V1 out the door for consumers to begin using and can depend on. After V1, maybe there is not a need for a V3 on exactly a year boundary from V2 (with breaking changes). We could go some period of time with V2.10.x as LTSR in 2020 and V2.20.x in 2021.

The impact to the version of Zowe is the community would have a LTSR source code tree at the V2.10.x level for any fixes and another LTSR source code tree some period of time later for V2.20.x.

Related topic to be discuss is what criteria do we want to establish to define when V1 is a LTSR. I recommend the SMP/E work needs to get done along with "new install and config" (aka the CUPIDS work) as well as better Logging and Messaging, Diagnostics. I've received feedback getting all this done in time for my proposed 3Q declaration of V1 LTSR is too ambitious but I think we make it as a goal and assess closer to time.

[armstro]

Zowe Support - LTSR Discussion .pptx Slides for Zowe face to face for discussion on LTSR and related topics

[Joe-Winchester]

Currently conformance is "self certification". I would like us to move away from this towards test compatability kit or TCK, which is where we have automation tests that a conformance product can run which tests whether an offering is compliant with the API/touchpoints of A desktop plugin or A CLI plugin or An API ML southbound server or A user of the base APIs or A user or the base CLI commands or an extender installing on top of Zowe adding plugins, southbound servers. The TCK protects the extender and also the TCK protects the Zowe squad from borking offerings that run on top of them

[alvin-tan]

Zowe LTSR Proposal for ZLC 0814a.pdf

as discussed at ZLC today

note: this is an example of what an LTSR could look like, not a final proposal

[dkelosky]

It's a trivial matter - but why LTSR instead of LTS? I hadn't come across LTSR and had to google it.

In Ubutu, Eclipse, Node.js, and many others I see LTS instead of LTSR. Should this be changed to be more familiar? 😄

[armstro]

Blame it on IBM-speak - https://www.ibm.com/support/pages/ibm-software-support-continuous-delivery-lifecycle-policy - I have no problem using LTS - well other than just need to train my brain to use it...LTSR just rolls off the tongue easier (for me). LTS going forward to be "open".

[dkelosky]

LTS sounds more familiar to me. MQ team apparently likes the LTS route too 😉 .

[MarkAckert]

LTS sounds good to me, this way I can stop repeating myself when I say LTSR Release

[armstro]

Based on Oct 9 ZLC meeting discussion on LTS, I propose the following as a stated support policy for V1.x of Zowe and introduction/preview of Zowe 2.0. This is a DRAFT ONLY - we need to edit and agreement by the ZLC and squad leads:

_The Zowe community intends to issue a release in 1Q2020 that will be serviceable via the vendor-neutral SMP/E install and PTF process currently previewed on zowe.org. (Insert link to Alpha.) In addition to SMP/E, the Zowe code is being restructured into binaries, configuration and instance data (aka CUPIDS) to provide more flexibility in the set up, execution and maintenance of Zowe. This 1Q2020 release will begin a new phase of the Continuous Delivery (CD) support model for Zowe. Consumers of Zowe will be urged to move to this upcoming release. Fixes and enhancements will be delivered in future releases of Zowe using the SMP/E PTF process. The pax file format will continue as an equally supported install option for quick and easy installs but without the benefits of SMP/E controls.

It is the Zowe community intent to deliver a Long Term Support (LTS) release in 2020 once a set of enhancements are made in Zowe V1. The planned enhancements are viewable via Zenhub in the Zowe community located here. (Insert link and pointer to Zenhub plug in.) The Zowe community intends to make Zowe 1.x a LTS once the issues tag as "LTSR" are shipped in Zowe V1.x. The LTS release will be supported by the open community for 2 years from the date of availability. LTS updates will fixes only - no new enhancements are planned.

At the time of the Zowe 1.x LTS release, Zowe 2.0 will become the active development release. Future enhancements will be delivered in 2.x. Any code changes in Zowe V2 that impact backward compatibility with 1.x will be clearly documented 1 year prior to end of support of 1.x for consumers of Zowe for their planning and migration purposes. _

What - if anything - to say about "switch"? (In seeking advice from dev/test teams in IBM, the use of config switches is an extra burden on testing with many more permutations and combinations due to switch settings - we need to discuss how we want to handle.)

Optional paragraph: ????? Subsequent releases after this 1Q2020 deliverable will - as best as possible - will have a configurable file setting to control whether new enhancements are enabled or not. The purpose of this "switch" to allow consumers of Zowe a degree of control over the enhancements in the execution of Zowe. Future enhancements will be delivered in 2.x included enabling - by default - the various 1.0 enhancements controlled by the configuration switch.

Another suggestion is Zowe how, when, if to provide a "deprecation warning message".....i.e. "use of parm "password" will be deprecated in V2".........

[armstro]

General comment is above policy needs additional work - plan is to adopt more node.js terminology and to provide visualization of the support plans.

[solsu01]

I iterated on Alvin/Bruce's release proposal: Zowe OSS 2019-20 Roadmap.pptx

Some details:

1. I would say 1.x has already been operating in "current" mode.
2. We started "Active LTS" when we said we will no longer introduce breaking changes into Zowe 1.x. I don't think we need to align SMP/e drop with "Active LTS" if we've already stopped introducing breaking changes into 1.x.
3. We should always start the "next" release of Zowe when the "current" one moves into "Active LTS" status. This is needed as the devs will need some release to put breaking changes in and ISVs can validate compatibility/prep for conformance using the "current" release.

[armstro]

@solsu01 Thanks for making another iteration on the LTS design.

For Zowe V1, I agree we are not making breaking changes so may be past the "current" phase but we need the SMP/E work to claim "Active LTS".

The SMP/E work is first step to doing what the team calls CUPIDS. This is needed before we can enter into Active LTS on z/OS. Today's Zowe z/OS install and config is not modular (my term). CUPIDS is addressing that requirement. CUPIDS = Componentized Update Package Install Distribute and Service. I think CLI is a "replace all" install process and has one instance on a laptop/desktop. The z/OS components need to allow delta changes (not full reinstall), modular startup, config files separated from runtime and the option of running multiple instances if needed.

[solsu01]

Ok, it might be better to just leave it as "Current" until SMP/e first drop then.

Updated: Zowe OSS 2019-20 Roadmap.pptx

[MarkAckert]

I agree with Bruce's comment on SMP/e. Without SMP/e, providing incremental maintenance is technically feasible but highly error prone and painful, requiring binary-by-binary replacements. Matt has previously described the current install method as a "breaking change" because every release requires clobbering the old one, or keeping the releases separate without native migration tooling.

We should always start the "next" release of Zowe when the "current" one moves into "Active LTS" status. This is needed as the devs will need some release to put breaking changes in and ISVs can validate compatibility/prep for conformance using the "current" release.

I don't think this should be required, but Zowe's "next" release timeline should start sometime before the prior "Active LTS" ends. Do we have a proposal for our Active LTS and Maintenance LTS windows? 1 year each - so 2 years total support from the day we declare "Active LTS"?

[jplinardon]

In terms of declaring active LTS, each squad has identified and tagged a list of items they want to have (zenhub and git issues are not in agreement on that front it seems). Are we constraining the timeline and telling the squads they have a finite amount of time to get as much done as possible, or are we going to let the squad complete each list prior to declaring LTS? It was my impression we were going to review the estimated effort and possibly negotiate

At a higher level, it feels like the CLI is moving faster than other squads. Is there any interest in de-synchronizing from other Zowe deliverables and making the CLI a semi-independent project within Zowe?

Jean-Philippe Linardon Director, Software Engineering Rocket Software 77 Fourth Avenue • Waltham, MA • 02451 • USA T: +1 781 684 2350 • E: jlinardon@rocketsoftware.commailto:jlinardon@rocketsoftware.com • W: www.rocketsoftware.comhttp://www.rocketsoftware.com/

From: Mark Ackert notifications@github.com Sent: Monday, October 21, 2019 4:49 PM To: zowe/zlc zlc@noreply.github.com Cc: Jean-Philippe Linardon jlinardon@rocketsoftware.com; Mention mention@noreply.github.com Subject: Re: [zowe/zlc] Zowe Long Term Support Plan (#72)

I agree with Bruce's comment on SMP/e. Without SMP/e, providing incremental maintenance is technically feasible but highly error prone and painful, requiring binary-by-binary replacements. Matt has previously described the current install method as a "breaking change" because every release requires clobbering the old one, or keeping the releases separate without native migration tooling.

We should always start the "next" release of Zowe when the "current" one moves into "Active LTS" status. This is needed as the devs will need some release to put breaking changes in and ISVs can validate compatibility/prep for conformance using the "current" release.

I don't think this should be required, but Zowe's "next" release timeline should start sometime before the prior "Active LTS" ends. Do we have a proposal for our Active LTS and Maintenance LTS windows? 1 year each - so 2 years total support from the day we declare "Active LTS"?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzowe%2Fzlc%2Fissues%2F72%3Femail_source%3Dnotifications%26email_token%3DAJKKTP3JUIK7TAUBRZXBLH3QPYIT7A5CNFSM4GPIGTFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB3XYZY%23issuecomment-544701543&data=02%7C01%7C%7Cae9df16a0f3348a47cd108d756681bd1%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637072877454167478&sdata=ymBq7bcrztPOseqaJXIyJGIgxN%2B35LDQcBnM8qCEZFk%3D&reserved=0, or unsubscribehttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJKKTP45K66JVPQ5TDLJYWLQPYIT7ANCNFSM4GPIGTFA&data=02%7C01%7C%7Cae9df16a0f3348a47cd108d756681bd1%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637072877454167478&sdata=Siz7lR3rqBxQVYF2y0dp%2FJj%2BTxsVtBzA5TcPzoMJCKY%3D&reserved=0.

================================ Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

[Joe-Winchester]

Suggested changes:  

The pax file format will continue as an equally supported install option for quick and easy installs but without the benefits of SMP/E controls.   I wanted to inject a bit more detail on what a pax release is, what a convenience build is, what an FMID and PTF are, so I have this suggested para:   The convenience build installed through USS shell script will continue as an equally supported install option for quick and easy installs. Convenience builds are created when the Zowe community completes an agile development milestone and the ZLC agrees to release a new software distribution.  This currently occurs monthly although this frequency is variable.  The convenience build that is deemed to be the LTS release will be version 1 of the Zowe SMP/E distribution and designated with the FMID AZWE001.  Subsequent distributions of Zowe milestone release software will be made available as a rollup PTF release that can be applied to the initial Zowe FMID, and will also be made available as a convenience build for customers who wish to install without SMP/E.  When the content of a milestone build contains changes that cannot be applied via PTF onto the FMID AZWE001 without requiring changes by software packages that have built Zowe extensions to the initial FMID release v1, then a new version v2 will be created for that software distribution that will be released as a new FMID AZWE002 that will require a fresh SMP/E install.     On a pedantic note, pax is a file compression format and not an install technology, and both the convenience build and SMP/E are distributed in pax file format (i.e. SMP/E download is a AZWE001.pax.Z file which is in .pax format).   Best regards,   Joe Winchester IBM z/OS Explorer Senior Technical Staff Member - Project Zowe Contributor zowe.org   Phone: 44-7749-965423 Twitter: @JoeWinchester    LinkedIn: joewinchester E-mail: winchest@uk.ibm.com     ----- Original message -----From: armstro notifications@github.comTo: zowe/zlc zlc@noreply.github.comCc: Joe-Winchester winchest@uk.ibm.com, Comment comment@noreply.github.comSubject: [EXTERNAL] Re: [zowe/zlc] Zowe Long Term Support Plan (#72)Date: Wed, Oct 16, 2019 1:44 PM  Based on Oct 9 ZLC meeting discussion on LTS, I propose the following as a stated support policy for V1.x of Zowe and introduction/preview of Zowe 2.0. This is a DRAFT ONLY - we need to edit and agreement by the ZLC and squad leads: The Zowe community intends to issue a release in 1Q2020 that will be serviceable via the vendor-neutral SMP/E install and PTF process currently previewed on zowe.org. (Insert link to Alpha.) In addition to SMP/E, the Zowe code is being restructured into binaries, configuration and instance data (aka CUPIDS) to provide more flexibility in the set up, execution and maintenance of Zowe. This 1Q2020 release will begin a new phase of the Continuous Delivery (CD) support model for Zowe. Consumers of Zowe will be urged to move to this upcoming release. Fixes and enhancements will be delivered in future releases of Zowe using the SMP/E PTF process. The pax file format will continue as an equally supported install option for quick and easy installs but without the benefits of SMP/E controls. It is the Zowe community intent to deliver a Long Term Support (LTS) release in 2020 once a set of enhancements are made in Zowe V1. The planned enhancements are viewable via Zenhub in the Zowe community located here. (Insert link and pointer to Zenhub plug in.) The Zowe community intends to make Zowe 1.x a LTS once the issues tag as "LTSR" are shipped in Zowe V1.x. The LTS release will be supported by the open community for 2 years from the date of availability. LTS updates will fixes only - no new enhancements are planned. At the time of the Zowe 1.x LTS release, Zowe 2.0 will become the active development release. Future enhancements will be delivered in 2.x. Any code changes in Zowe V2 that impact backward compatibility with 1.x will be clearly documented 1 year prior to end of support of 1.x for consumers of Zowe for their planning and migration purposes. What - if anything - to say about "switch"? (In seeking advice from dev/test teams in IBM, the use of config switches is an extra burden on testing with many more permutations and combinations due to switch settings - we need to discuss how we want to handle.) Optional paragraph: ?????Subsequent releases after this 1Q2020 deliverable will - as best as possible - will have a configurable file setting to control whether new enhancements are enabled or not. The purpose of this "switch" to allow consumers of Zowe a degree of control over the enhancements in the execution of Zowe. Future enhancements will be delivered in 2.x included enabling - by default - the various 1.0 enhancements controlled by the configuration switch. Another suggestion is Zowe how, when, if to provide a "deprecation warning message".....i.e. "use of parm "password" will be deprecated in V2"......... —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.  Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[solsu01]

@MarkAckert

Do we have a proposal for our Active LTS and Maintenance LTS windows? 1 year each - so 2 years total support from the day we declare "Active LTS"?

In my revision to Alvin's proposal (Slide 2 on Zowe OSS 2019-20 Roadmap.pptx), I am proposing 1 year of Active LTS followed by 1 year of Maintenance LTS which adds up to 2 years of total support from the day we declare Active LTS.

I think it would be good to have every release in LTS (combination of active and maintenance modes) for 2 years. This seems to be the sweet spot in the mainframe world since z/OS releases are once every 2 years now. People stagger their other software upgrades on z/OS on the same 2 year cycle.

[armstro]

Zowe.OSS.2019-20.Roadmap Rev 1.pptx

OK - thanks for the comments. See Rev 1 of deck - removed slide 1, created new slide 2. Slide 3 comes from the node.js site https://nodejs.org/en/about/releases/

1) We said we liked the Node.js description of current, active and maintenance so I have made an attempt to draw chart and create bullets along their policy. We can discuss in ZLC tomorrow (I hope). 2) Quick summary - I say we are in "current" now but it will not be the norm to have such a long "current" ....Node.js says "current" will be 6 months - we can debate if that is right for Zowe. 3) I find predicting when we declare Current to Active and Active to Maintenance hard to predict - node appears to give a month of year - do we have to say quarter? The chart I created is 1H or 2H of a year.

Related topics from comments above 1) Do we have the CLI go ahead and make breaking changes in V1 "current"? 2) Do we allow the squads to follow through on completing the items marked LTSR at their own pace (don't set a date) or do we set a date (mid 2020?) and discuss MVP to declare Maintenance LTS?

[solsu01]

Thanks for iterating on the proposal @armstro .

I say we are in "current" now but it will not be the norm to have such a long "current" ....Node.js says "current" will be 6 months

I chalk it up to the longer "current" phase due to this being a new v1.x project.

With respect to the iteration on the proposal, I see a few differences of note in the new slide 2:

1. The length of LTS of v1.0 was extended to 1H2022 rather than ending at 1H2021. ^ I agree that LTS releases should generally be 2 years in length of LTS (Active + Maintenance), but v1.x usually carries a negative connotation with it in terms of stability. It's viewed as the first attempt which might not be quite production ready. If we think this perception is true, do we want to extend the length of 1.x or sunset it a bit faster so we can focus our efforts on 2.x which may not carry similar perception baggage?

2. v1.x and v2.x are overlapping in Active LTS and Maintenance LTS ^ I'm not sure I understand the purpose of 2 majors releases with mostly overlapping Active/Maint LTS where v2.x is in maintenance LTS for only 6 months longer than 1.x.

[armstro]

Zowe.OSS.2019-20.Roadmap Rev 3.pptx Attaching another rev of the lifecycle chart along with some additional comments.

1) Definition of "critical" defect needs some discussion - I included the IBM definition of Sev 1 that does not exactly apply to open community since community is not geared toward "system down" and "need response in hours". I welcome input on how to define critical. I added some key words in the footnote of chart.

2) My bullets on chart and page 2 are the beginnings of a lifecycle "policy" - I welcome additional points - again my intent is to follow something similar to node.js team (short and sweet)

3) I think we still have discussion on how we handle the CLI??? Does CLI stay in sync with z/OS components? Didn't we declare an Active or Current CLI branch (with some breaking changes)?

Actions for next ZLC:

• Ask squad leads for their target to complete LTSR items in their backlog. @nkocsis need some help on who to invite
• Need vote: There was consensus (but not a quorum) to get to V1 Active LTS in 1Q2020
• Need vote: I think ZLC view (although not voted) is to get to V1 maintenance release by mid 2020.
• If V1 Active LTS or V1 Maintenance targets not possible ZLC and squads need to prioritize backlog.
• Assume we can agree on general description, timeline and policy words - I'd like to discuss posting to Zowe.org for public viewing and "announce"......unless we want to hold off until Active LTS is ready?

[solsu01]

Looks great!

I think we still have discussion on how we handle the CLI??? Does CLI stay in sync with z/OS components? Didn't we declare an Active or Current CLI branch (with some breaking changes)?

I believe the CLI is in a good place to fall into this same cycle. I had some chats with the CLI squad and they're looking forward to aligning with the Zowe release cycle.

From ppt:

Maintenance LTS release status is "long-term support", which typically guarantees that critical1 bugs will be fixed.

Both Active LTS and Maintenance LTS are "long term support" - we want users to feel confident about both phases of LTS. We probably shouldn't make statements that make the Active LTS phase seem any less "safer" than Maintenance LTS.

The exact dates of Current to Active LTS and to Maintenance release will vary depending on the judgement of the Zowe community

Exact dates can vary, but I do think we need to publicize a roundabout date range (3-4 week range?) well ahead, so extenders can plan to announce Day 1 support for their Zowe extensions with the new Active LTS.

A new Current release will first use PAX format for easy download and install by consumers and later become a new SMP/E PID when becomes Active LTS release

What is a PID? If it's IBM internal terminology, we should try to avoid using it in Zowe release descriptions. If it's standard SMP/e terminology, it's probably fine.

A maintenance release will be a new FMID in SMP/E to become fixes-only target

Are you saying the transition from Active LTS to Maintenance LTS will result in a new FMID in SMP/e?

[jlvignaudCA]

ON defect severity 1, Broadcom definition is

System-down or a product-inoperative condition impacting production environment, and an immediate workaround is not available.

Criteria:

Causes downtime

Irrecoverable data corruption

Daily application crash

Critical security exploits

Blocks a critical business functionality.

/Jean-Louis

On Fri, Oct 25, 2019 at 2:24 AM Sujay Solomon notifications@github.com wrote:

Looks great!

I think we still have discussion on how we handle the CLI??? Does CLI stay in sync with z/OS components? Didn't we declare an Active or Current CLI branch (with some breaking changes)?

I believe the CLI is in a good place to fall into this same cycle. I had some chats with the CLI squad and they're looking forward to aligning with the Zowe release cycle.

From ppt:

Maintenance LTS release status is "long-term support", which typically guarantees that critical1 bugs will be fixed.

Both Active LTS and Maintenance LTS are "long term support" - we want users to feel confident about both phases of LTS. We probably shouldn't make statements that make the Active LTS phase seem any less "safer" than Maintenance LTS.

The exact dates of Current to Active LTS and to Maintenance release will vary depending on the judgement of the Zowe community

Exact dates can vary, but I do think we need to publicize a roundabout date range (3-4 week range?) well ahead, so extenders can plan to announce Day 1 support for their Zowe extensions with the new Active LTS.

A new Current release will first use PAX format for easy download and install by consumers and later become a new SMP/E PID when becomes Active LTS release

What is a PID? If it's IBM internal terminology, we should try to avoid using it in Zowe release descriptions. If it's standard SMP/e terminology, it's probably fine.

A maintenance release will be a new FMID in SMP/E to become fixes-only target

Are you saying the transition from Active LTS to Maintenance LTS will result in a new FMID in SMP/e?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/zowe/zlc/issues/72?email_source=notifications&email_token=AKICKMXASIKLSY46BJGJNITQQI4CPA5CNFSM4GPIGTFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECGZZ7Q#issuecomment-546151678, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKICKMQ6HI2JFGLRLI5V5UDQQI4CPANCNFSM4GPIGTFA .

-- Jean-Louis Vignaud Product Management Broadcom, MF Business Division +420 770 146 136

[armstro]

Zowe.OSS.2019-20.Roadmap Rev 4.pptx

Thanks for review and feedback - I've incorporated input.

With regard to use of the term FMID - while that is IBM jargon, I think it is an understood concept on z/OS. The open community is planning to produce both pax and FMID formats. I agree PID is not in the scope of the open community plans.

Are you saying the transition from Active LTS to Maintenance LTS will result in a new FMID in SMP/e?

Yes - we need to confirm with the CUPIDS team but I recall creating a Maintenance LTS will cause two parallel actions 1) a maintenance only source code branch will be created in github (please forgive if my terminology is not 100% correct) 2) the SMP/E process will have a new FMID to distinguish between the Active and Maintenance branches......but we need to confirm.

[solsu01]

@armstro on FMID change:

I don't think Active LTS -> Maintenance LTS transition will cause an FMID change for the ongoing SMP/e release package. I spoke with @vvvlc (CUPIDS member) and he thinks FMID will remain the same for that release across Active -> Maintenance transition. However, around that transition time is when we begin Active LTS for the next release, which would result in a new FMID being defined in a different SMP/e release package.

[MarkAckert]

My understanding was also that each major release version of Zowe requires a different FMID.

I would expect the FMID to be stable within a single Zowe release. If a user picks up Active LTS and applies all maintenance PTFs to it, they should in effect end up with the Maintenance LTS.

If a user wanted to upgrade from v1 to v2 Zowe (say, v1 EOL Maintenance to v2 active/maintenance) - which means two different FMIDs - what does that upgrade process look like?

[armstro]

My bad on FMIDs - I will fix ......we need to discuss upgrade process......I'll post (near final) deck shortly

Zowe.OSS.2019-20.Roadmap Rev 5.pptx

Sounds like we need to discuss upgrade path but I'd like to get closure on this LTS topic first and post to the wider community when we are ready. I think we can expand on upgrade process policy definition once the squads have had more think time on it.

[solsu01]

Almost there!

A new Current release will first use PAX format for easy download and install by consumers and later become a new SMP/E FMID when becomes Active LTS release

We should qualify this as "For z/OS Components...", and then have a similar statement for client stuff... "For the CLI and associated plugins, a new Current release will first use the @xyz npm scope for developer and testing use and an @abc npm scope will be introduced for for the Active LTS phase." @MarkAckert could you help polish this statement?

Also I'm not sure if the original note is fully clear - because for both Current and Active LTS, the delivery package is a PAX. It's just that for Current, it's a PAX without SMP/e, while for Active LTS, it's a PAX with SMP/e. Not certain on this, but figured it's worth clarifying.

[armstro]

Thanks - and I need to confirm Current will be PAX only - I might be wrong

• we are doing pax and FMID now and since it is automated build we may do the same for all releases going forward.

Bruce Armstrong IBM System Z Offering Manager- zowe.org 4205 S MIAMI BLVD, DURHAM NC 27703-9141 Email: armstrob@us.ibm.com Tel: 919-254-8773 Cell: 919-931-3132

From: Sujay Solomon notifications@github.com To: zowe/zlc zlc@noreply.github.com Cc: Bruce Armstrong armstrob@us.ibm.com, Mention mention@noreply.github.com Date: 10/25/2019 03:26 PM Subject: [EXTERNAL] Re: [zowe/zlc] Zowe Long Term Support Plan (#72)

Almost there! A new Current release will first use PAX format for easy download and install by consumers and later become a new SMP/E FMID when becomes Active LTS release We should qualify this as "For z/OS Components...", and then have a similar statement for how "For the CLI and associated plugins, a new Current release will first use the @xyz npm scope for developer and testing use and an @abc npm scope will be introduced for for the Active LTS phase." @MarkAckert could you help polish this statement? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[Joe-Winchester]

My understanding was also that each major release version of Zowe requires a different FMID.

Yes - the FMID AZWE001 is for version 1. The FMID AZWE002 will be for version 2. Within version 1 we can go from 1.6.0 through to 1.999.999 or higher, but we can't bump the first digit without a new FMID.

I would expect the FMID to be stable within a single Zowe release. If a user picks up Active LTS and applies all maintenance PTFs to it, they should in effect end up with the Maintenance LTS.

Correct.
If we wanted to we could every quarter or other frequency create a rollup single downloadable build that was "initial FMID + the last rollup PTF" just to make it easier than having to download the initial FMID and apply PTF maintenance every time a new customer does their first Zowe install.

If a user wanted to upgrade from v1 to v2 Zowe (say, v1 EOL Maintenance to v2 active/maintenance) - which means two different FMIDs - what does that upgrade process look like?

AZWE001 will install into /usr/lpp/zowe/v1 AZWE002 will install into /usr/lpp/zowe/v2

They will be isolated from each other so no v2 content will leak onto v1. Extensions built to work with v1 may or may not work with v2.

For an upgrade for a customer who has v1 with configuration and extensions that they wish to propogate to v2 I think we'll have to cross that bridge when we get there. I imagine we'll have some kind of migration script or set of docs to help with this trying to make it as easy and seamless as we can, but until we know what the v2 breaking change is that precipitated v2 being created it's hard to predict.

[MikeBauerCA]

Typically distribution tags are used for communicating different distributions such as lts, latest, etc. Scopes are typically used for grouping related packages together such as packages that are part of the same product/organization/entity.

The current proposal for Zowe LTS is very similar to what Node does (https://nodejs.org/en/about/releases/). From an npm perspective, I would suggest distributing packages in a similar manner. For example, issuing an npm view node command yields the following:

So, for Zowe CLI and Zowe CLI plug-ins, we could have a latest distribution for active development, v1-lts for a long term supported version of Zowe v1, v2-lts for a long term supported version of Zowe v2, etc. All packages installed with the same distribution tag should be compatible.

We previously planned to use three tags latest, lts-incremental, and lts-stable and migrate distributions through these phases. However, this would cause folks using an lts-incremental or lts-stable tag to need to adjust as releases progressed from Current to Active LTS to Maintenance LTS. Node's strategy accommodates this better by including the major version in the distribution tag so folks will not need to change as releases progress from Current to Active LTS to Maintenance LTS.

[armstro]

Zowe.OSS.2019-20.Roadmap Rev 6.pptx Posting what I think is the "near final" deck describing LTS

• I removed the bullet saying "Current" would be pax file - we can debate if it matters in the upcoming ZLC. I think build automation will produce FMID and PAX for all releases (including Current) - it can be up to the consumer which format they use.
• Also for discussion - any further definition of "critical" for fixes to Maintenance LTS
• Additional topic for discussion is how/if z/OS components can have any distribution tags mentioned above for NPM CLI.

[MikeBauerCA]

After discussion, perhaps zowe1-lts and zowe2-lts would be a better naming standard to communicate that the tag is a reference to the greater Zowe solution instead of the individual CLI and CLI plugin versions. One significant purpose of these tags is to eliminate the need for a complex compatibility matrix.

[MarkAckert]

After discussion, perhaps zowe1-lts and zowe2-lts would be a better naming standard to communicate that the tag is a reference to the greater Zowe solution instead of the individual CLI and CLI plugin versions. One significant purpose of these tags is to eliminate the need for a complex compatibility matrix.

Agree with the direction, how about v1-lts and v2-lts ? Using zowe in the tag seems redundant when the package scope for our artifacts will be @zowe. i.e., @zowe/cli@v2-lts vs @zowe/cli@zowe2-lts.

[dkelosky]

good point @MarkAckert that Zowe could be redundant. Without the redundant part, someone may think @zowe/cli@v1-lts would obtain version 1 of the CLI (following angular's model):

What do you think?

[MarkAckert]

I see the confusion, I'm not sure what the best answer is here.

I was originally confused by zowe2-lts (thinking it was analogous to the angular v2-lts), so maybe a small change like @zowe/cli@zowe-v2-lts would have been clearer to me? I'm not sure...and I may have been the exception reading it that way. Are there any other projects out there which tag LTS in reference to their parent release cycle?

[dkelosky]

loosely, perhaps the typings packages - like @types/node and @types/express - which map to versions of typescript compiler but not to the versions of the typings.

[solsu01]

In these suggestions, does zowe-v1 and zowe-v2 refer to the "greater" Zowe 1.x an Zowe 2.x ?

[MarkAckert]

In these suggestions, does zowe-v1 and zowe-v2 refer to the "greater" Zowe 1.x an Zowe 2.x ?

Correct.

I support tags following the "greater" Zowe version schema, as that aligns us with zowe.org deliverables and keeps our version discussions with extenders/stakeholders focused on the "greater" Zowe releases. If we need more tags in the future for developers or other types of users, we can add them at that point.

[armstro]

Please find attached the proposed zowe.org design of describing Zowe LTS policy. Many thanks to @nannanli for her working on this. Please comment here on any issues or concerns. We can discuss at tomorrow (Nov 6) ZLC meeting assuming we have a quorum.

LTS_Zoweorg_Design.pdf

[solsu01]

The draft looks great!!

My only comment is that there are dates "Feb 8th" mentioned in the charts. Is this ok? Are we ready to commit to that date?