K2 Product Support and Release Strategy
This article describes Nintex’s official release strategy for K2 Software. It also includes information on how product releases may affect version support. Additionally, support plans for third-party software (including Microsoft Products) are included in this article. Please contact your local Nintex representative with any questions.
- Third-Party software support plan
- K2 software support plan
Useful Links to other articles
- K2 Product Releases and Build Numbers - lists the released versions and build numbers, and contains links to the release notes for that release
- How to determine the installed K2 software version, Cumulative Updates, and Fix Packs - describes how to determine which version/CU or FP are installed in a K2 environment
- Product Compatibility, Integration and Support - a matrix that lists compatibility and support information for various versions of K2 with versions of third-party software
- Support & Services Policies - terms and conditions for support policies, such as Extended Term Support Policies, K2 Software Support Policies, and Virtual Services Policies
This article is effective 6 May 2021. Unless otherwise noted, the information contained in this document applies to the K2 Five, K2 Cloud, K2 blackpearl, K2 smartforms and K2 connect product lines. The K2.net 2003 platform is not covered by this document.
K2 software integrates with various third-party systems and applications. Nintex will plan to support third-party integration per the following guidelines:
- Nintex tests our integration with the third-party version available at the beginning of our testing cycle. These versions are listed in the compatibility matrix.
- If the third-party vendor maintains backwards compatibility with the APIs and integration points K2 software uses, minor releases (such as service packs, cumulative updates, or patches) of third-party products are supported.
- If the third-party vendor makes a breaking change to an integration point with K2, we will react to that change through our normal support channels and update cycles.
- K2 releases will drop support for third-party products that are no longer supported by those third parties.
- Any support for new versions of third-party products or additional third-party products not currently integrated with K2 software will be communicated as Nintex develops plans, if any, for integration.
Nintex does not explicitly test or support K2 software delivered through other mechanisms, such as specific MDMs. Nintex will only support issues that are able to be reproduced in an App Store signed version of the app. If an issue is found with an app that a customer has re-signed using an enterprise profile that cannot be reproduced with the app store version, Nintex will not support it and will not provide a fix for the issue.
All Server Components and Client Components in an environment* must be on the same Major Release and Minor Release. Additionally, all Server Components must have the same Cumulative Update (CU) / Fix Pack (FP). For example, if K2 Server has 4.7 installed, the K2 for SharePoint components in the same environment must also have 4.7 installed. K2 highly recommends that all Client Components be at the same CU/FP level as the Server Components in the same environment. Refer to the version release notes for any known considerations about Server/Client components compatibility.
If your organization has multiple environments (e.g., Dev, Test, Production) and you are upgrading or updating environments, it is expected that non-Production environments (e.g., Dev and Test) will be on a higher release and CU/FP level than Production environments, at least while the necessary testing is completed. In these cases, it is not always possible to use the K2 Package and Deployment (P&D) tools or client components between environments that are not on the same release and update level. From a P&D tool perspective, it is usually possible to P&D from a lower version to a higher version, but not necessarily the other way around. K2 recommends, where possible, to deploy only between environments that are on the same version and CU/FP level.
*A K2 “environment” is any combination of K2 components that utilize a single instance of K2 databases. For example, an installation with two load-balanced K2 Servers, two SharePoint web front-ends running K2 for SharePoint components, and 10 developers running K2 for Visual Studio components, all sharing an instance of the K2 database(s), would be considered an “environment”. In this example, the K2 database, the K2 servers and the K2 for SharePoint components are considered “Server Components” and the K2 for Visual Studio components are considered “Client Components.”, and they all reside in an "environment".
When possible, Nintex will minimize the impact of API changes to attempt to maintain backwards compatibility with previous K2 software releases. However, Nintex reserves the right to make breaking changes in Major and Minor releases. Nintex will not introduce breaking changes in CUs and FPs. Wherever possible, breaking changes in APIs will be described in that version's release notes. If you use APIs that have changed in your custom code, you may need to update custom code to cater for possible breaking changes.
If you have upgraded to K2 Five or K2 Cloud from a previous version (i.e., K2 blackpearl or K2 Appit), several components used in the old version are deprecated and are now marked as legacy components. Nintex recommends that any new development of K2 applications is done on the latest components to take advantage of the newest features.
While artifacts created in legacy designers or integrating with legacy APIs will continue to run, we reserve the right to remove and deprecate those components in the future. Legacy components remain supported during the support window for the release in which they are installed.
No legacy component will receive additional features. If there are features in the legacy components that are not yet in the newer versions, please log your feedback to nintex.uservoice.com for prioritization.
Nintex supports every product release (major releases and minor releases) for a minimum of two years. This is known as the standard support lifecycle of a K2 release, or a “Supported Release.” During this standard lifecycle, customers with an active Support agreement have access to support and code fixes.
K2 products will enter an “End-of-Life Release” status after the standard support lifecycle ends. When a K2 product release reaches End-of-Life, development of new code fixes will cease unless a crucial fix is required for a production outage. Security, stability and performance release packs will continue until the K2 product reaches the end of Extended support. To receive code fixes and have access to support, you must have an active support agreement in place.
Once a K2 product has reached the end of Extended support, no new code fixes will be developed.Nintex will endeavor to assist in providing suggested updates in solution design or implementing a workaround. To receive existing code fixes and have access to Support, you must have an active support agreement in place.
This includes all related K2 components based on the Compatibility Matrix.
|Product||Standard Support Lifecycle Begins||Standard Support Lifecycle Ends||End of Extended Support|
|K2 4.6.11 and earlier||All versions are end of life|
|K2 4.7||22 September 2016||31 December 2019||31 December 2023|
|K2 Five (5.0)||1 November 2017||31 December 2019||31 December 2021|
|K2 Five (5.1)||30 April 2018||30 April 2020||30 April 2022|
|K2 Five (5.2)||16 October 2018||31 October 2020||31 October 2022|
|K2 Five (5.3)||3 May 2019||31 May 2021||31 May 2023|
|K2 Five (5.4)||23 June 2020||30 June 2022||30 June 2024|