This chapter defines the manner in which ZyLAB releases software. ZyLAB creates and maintains a number of eDiscovery and Information Management products; for a detailed listing of our products please consult our website, www.zylab.com.
ZyLAB uses the following terms:
- Backward Compatibility
A Product is a unit priced and licensed separately. A Product can be either a Platform or a Bundle.
A Platform is a framework on which Bundles can be run. A Platform has its own release cycle and is developed, tested and released independently of Bundles.
A Bundle is a set of functionalities that is built on top of the Platform. A Bundle has its own release cycle and is developed, tested and released independently of other Products. Dependencies may exist between a Bundle and the Platform. When a new ZyLAB platform is released, compatibility with dependent Bundles may be affected. ZyLAB will determine when and whether to update dependent Bundles. The dependencies of a Bundle are described in the release notes of the relevant Bundle. Refer to this document for more detailed information.
A Module is an individual unit of functionality that forms the basis of a Product. Modules are never released separately. Consequently, modules do not have versions. Inter-modular dependency between modules of the same Product exists. For example, the Culling Module is dependent on the Email Conversion Module, both from EDRM Bundle 1.0. It therefore is not possible to use the Culling Module from EDRM Bundle 1.0 with the Email Conversion Module from EDRM Bundle 2.0.
A System is a combination of Platform and one or more Bundles targeted at a specific market. A documented and defensible methodology is usually a part of every System.
In order to innovate, ZyLAB must periodically make changes to the way in which its Products function. To minimize the impact on the production environments of our customers, ZyLAB endeavors to maintain backward compatibility. When a guarantee of backward compatibility is provided, customers may upgrade to new versions of Products without the immediate need to make changes to their implementations, although in order to gain maximum advantage of new functionality, customers are advised to adapt their implementations after the upgrade. In cases of an upgrade to a Major Release, migration might be necessary directly after the upgrade. In these cases ZyLAB will usually create an automated migration path to assist customers in upgrading their implementations and reduce the impact of the change. The Release Notes of a Product will specify whether adaptations to implementations are necessary and how ZyLAB supports its customers in this process.
Although ZyLAB will try to incorporate all functional features of previous versions of the standard software in new versions of the software without modifications, ZyLAB reserves the right to deprecate functionality and eventually remove it from the Products. ZyLAB aims to announce the deprecation in the relevant Release Notes of a product and in the implementation manuals provided. When a deprecation notice is given, customers must plan to adapt their implementations correspondently.
There are four release types:
- Major Release
- Minor Release
- Service Pack
- Hot Fix
A Major Release offers new and innovative functionality to customers, while providing no guarantees regarding backward compatibility. The characteristics of a Major Release are:
- Major Releases have a name created by appending a sequential number and ".0" to the corresponding product name (for example, ZyLAB Information Management Platform 7.0)
- Major Releases include enhancements in product functionality and capabilities
- Major Releases include bug fixes and stability enhancements based on previous releases
- Major Releases are self-contained for installation purposes (they do not require any previous release to be installed)
- Major Releases may contain non-backward-compatible changes to public programming interfaces and storage formats and thus require adaptations and migrations of the customers’ implementations
- Major Releases may contain changes to platform support
- Major Releases are rigorously regression tested by ZyLAB’s Testing Department, including interoperability testing with other ZyLAB products
A Minor Release offers functionality enhancements while maintaining backward compatibility with the preceding release. The characteristics of a Minor Release are:
- Minor Releases have a name created by appending a sequential decimal number to the corresponding Major Release name (for example, ZyLAB Information Management Platform 6.2)
- Minor Releases include enhancements in product functionality and capabilities
- Minor Releases include bug fixes and stability enhancements based on previous releases
- Minor Releases are self-contained for installation purposes (they do not require any previous release to be installed)
- Minor Releases contain only backward-compatible changes to public programming interfaces and storage formats and thus do not require major adaptations and migrations of customer's implementations
- Minor Releases may contain changes to platform support
- Minor Releases are rigorously regression tested by ZyLAB’s Testing Department, including interoperability testing with other ZyLAB products
Service Packs, based on the corresponding Major or Minor Release, contain bug fixes and stability enhancements only. The characteristics include:
- Service Packs have a name created by appending "SP" and a sequential number to the corresponding release name (for example, ZyLAB Information Management Platform 6.0 SP2)
- Service Packs contain all Hot Fixes subsequent to the previous Major Release, Minor Release or Service Pack
- Service Packs do not include new functionality or functionality enhancements
- Service Packs are self-contained for installation purposes (they do not require any previous release to be installed)
- Service Packs do not contain significant changes, so do not require adaptations or migrations of customers’ implementations
- Service Packs may contain changes to platform support
- Service Packs are rigorously regression tested by ZyLAB’s Testing Department
Hot Fixes make critical updates available. Customers may request a Hot Fix for a critical issue at any time; however, ZyLAB will make the final decision on whether a Hot Fix is released, based on technical complexity, customer business requirements, and schedules. Generally, a Hot Fix is only considered for the correction of blocking issues and is only made available if the issue has not been fixed in an active or mature Major Release, Minor Release or Service Pack. Hot Fixes are built and tested for a particular customer's environment; therefore Hot Fixes are not transferable to other environments or configurations unless explicitly stated. The README file, shipped with every Hot Fix, describes all potential dependencies of a Hot Fix on other Hot Fixes. Characteristics include:
- Hot Fixes have a number associated with the issue fixed by a Hot Fix (for example, EDRM 1.0 - CAS-04061-9VKDK6). This indicates a Hot Fix for the issue described in case number CAS-04061-9VKDK6 which is made and tested on EDRM 1.0)
- Hot Fixes are not self-contained (they require the corresponding Release or Service Pack and, optionally, previous Hot Fixes to be installed in order to be successfully installed)
- Hot Fixes are not released according to a release schedule, but on per-need basis
- Hot Fixes are tested by the customer itself and by ZyLAB’s Customer Support
Frequency of Releases
In order to give customers clarity on when they can expect updates, ZyLAB aims to have a predictable schedule for releasing Major Releases, Minor Releases and Service Packs. As a rule of thumb, ZyLAB aims for the following frequency for its main product, ZyLAB Information Management Platform:
- Major Release: released every 36 months
- Minor Release: released every 12 months
- Service Pack: released every 6 months
- Hot Fix: released on demand and subject to an explicit decision
A dependent product is typically updated within a period of approximately 3 months in order to maintain inter-product dependency. Depending on the impact on the dependent product, updates for inter-product dependency are delivered in Major Releases, Minor Releases or Service Packs.
ZyLAB Release Life Cycle
Releases of ZyLAB products are subject to the following phases in its Release Life Cycle:
- End of Life
During the developmental phase of the Release Life Cycle, ZyLAB may decide to make Beta releases of its products available. Beta releases are not supported; no Service Packs or Hot Fixes will be issued.
- Upon its availability, a new release immediately enters the active phase of the Release Life Cycle. After a new active release becomes available the following rules apply:
- Upon availability of the next Major Release of a product, the current active release enters the mature phase and the current mature release enters the end of life phase
- Upon availability of the next Minor Release of a product, the current active release enters the end of life phase
- Upon availability of the next Service Pack of a product, the current active release enters the end of life phase
Active releases are actively sold and supported. ZyLAB may upgrade active releases through Minor Releases and Service Packs, and bring out Hot Fixes for critical updates.
Mature releases are supported releases. Hot Fixes for critical updates may be released however; ZyLAB will not roll out Major Releases, Minor Releases or Service Packs. For releases in this phase, customers are advised to plan the migration to an active release.
End of Life
Releases in the End of Life phase of the Release Life Cycle are supported by ZyLAB Customer Support subject to the availability of trained personnel and resources. No Service Packs or Hot Fixes will be issued.
You can download a PDF version of our Release Policy here.