Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Zowe Long Term Support Plan #72

Open
MarkAckert opened this issue Jan 10, 2019 · 54 comments

Comments

@MarkAckert
Copy link
Member

@MarkAckert MarkAckert commented Jan 10, 2019

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

This comment has been minimized.

Copy link
Contributor

@hogstrom hogstrom commented Jan 10, 2019

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

This comment has been minimized.

Copy link
Member Author

@MarkAckert MarkAckert commented Jan 10, 2019

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

This comment has been minimized.

Copy link
Member

@Joe-Winchester Joe-Winchester commented Jan 11, 2019

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

This comment has been minimized.

Copy link
Contributor

@hogstrom hogstrom commented Jan 29, 2019

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

This comment has been minimized.

Copy link
Member Author

@MarkAckert MarkAckert commented Jan 30, 2019

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

This comment has been minimized.

Copy link
Contributor

@hogstrom hogstrom commented May 1, 2019

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 hogstrom changed the title Post-1.0.0 Versioning & Release updates Zowe Long Term Support Plan May 8, 2019
@hogstrom

This comment has been minimized.

Copy link
Contributor

@hogstrom hogstrom commented May 22, 2019

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

@armstro

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented May 28, 2019

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

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented May 28, 2019

@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

This comment has been minimized.

Copy link
Member

@jplinardon jplinardon commented May 30, 2019

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

@armstro

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented Jun 3, 2019

@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

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented Aug 4, 2019

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

@Joe-Winchester

This comment has been minimized.

Copy link
Member

@Joe-Winchester Joe-Winchester commented Aug 14, 2019

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

This comment has been minimized.

Copy link
Contributor

@alvin-tan alvin-tan commented Aug 14, 2019

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

This comment has been minimized.

Copy link

@dkelosky dkelosky commented Oct 11, 2019

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

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented Oct 11, 2019

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

This comment has been minimized.

Copy link

@dkelosky dkelosky commented Oct 11, 2019

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

@MarkAckert

This comment has been minimized.

Copy link
Member Author

@MarkAckert MarkAckert commented Oct 11, 2019

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

@armstro

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented Oct 16, 2019

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

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented Oct 16, 2019

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

This comment has been minimized.

Copy link

@solsu01 solsu01 commented Oct 21, 2019

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

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented Oct 21, 2019

@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

This comment has been minimized.

Copy link

@solsu01 solsu01 commented Oct 21, 2019

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

This comment has been minimized.

Copy link
Member Author

@MarkAckert MarkAckert commented Oct 21, 2019

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

This comment has been minimized.

Copy link
Member

@jplinardon jplinardon commented Oct 21, 2019

@Joe-Winchester

This comment has been minimized.

Copy link
Member

@Joe-Winchester Joe-Winchester commented Oct 22, 2019

@solsu01

This comment has been minimized.

Copy link

@solsu01 solsu01 commented Oct 22, 2019

@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

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented Oct 22, 2019

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

This comment has been minimized.

Copy link

@solsu01 solsu01 commented Oct 22, 2019

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

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented Oct 24, 2019

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

This comment has been minimized.

Copy link

@solsu01 solsu01 commented Oct 25, 2019

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

This comment has been minimized.

Copy link
Contributor

@jlvignaudCA jlvignaudCA commented Oct 25, 2019

@armstro

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented Oct 25, 2019

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

This comment has been minimized.

Copy link

@solsu01 solsu01 commented Oct 25, 2019

@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

This comment has been minimized.

Copy link
Member Author

@MarkAckert MarkAckert commented Oct 25, 2019

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

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented Oct 25, 2019

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

This comment has been minimized.

Copy link

@solsu01 solsu01 commented Oct 25, 2019

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

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented Oct 25, 2019

@Joe-Winchester

This comment has been minimized.

Copy link
Member

@Joe-Winchester Joe-Winchester commented Oct 28, 2019

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

This comment has been minimized.

Copy link

@MikeBauerCA MikeBauerCA commented Oct 28, 2019

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:
image

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

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented Oct 30, 2019

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

This comment has been minimized.

Copy link

@MikeBauerCA MikeBauerCA commented Nov 1, 2019

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

This comment has been minimized.

Copy link
Member Author

@MarkAckert MarkAckert commented Nov 4, 2019

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

This comment has been minimized.

Copy link

@dkelosky dkelosky commented Nov 4, 2019

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):
image

What do you think?

@MarkAckert

This comment has been minimized.

Copy link
Member Author

@MarkAckert MarkAckert commented Nov 4, 2019

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

This comment has been minimized.

Copy link

@dkelosky dkelosky commented Nov 4, 2019

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

This comment has been minimized.

Copy link

@solsu01 solsu01 commented Nov 4, 2019

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

@MarkAckert

This comment has been minimized.

Copy link
Member Author

@MarkAckert MarkAckert commented Nov 4, 2019

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

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented Nov 5, 2019

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

This comment has been minimized.

Copy link

@solsu01 solsu01 commented Nov 5, 2019

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?

@armstro

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented Nov 5, 2019

@armstro

This comment has been minimized.

Copy link
Contributor

@armstro armstro commented Nov 20, 2019

Zowe.OSS.2019-20.Roadmap Rev 7.pptx
Modified chart and added bullet regarding backward compatibility

@jplinardon

This comment has been minimized.

Copy link
Member

@jplinardon jplinardon commented Nov 21, 2019

I think this draft gives us the necessary flexibility to commit and move forward. I propose we move to vote on this before year end.

@MarkAckert

This comment has been minimized.

Copy link
Member Author

@MarkAckert MarkAckert commented Nov 26, 2019

What do we say about Conformance v1 (or Conformance 2019) users? Will they continue to work against Zowe v1.x Active LTS?

We discussed last week on the ZLC about breaking changes into the v1.x LTS drop....and this impacts for Conformance v1. If we intend to break, we must give the 60-90 day heads up if I recall correctly...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.