Product discontinuance and obsolescence
Lifecycle of product version V.U-P
| event | discontinuance date | obsolescence date 1 6 |
|---|---|---|
| availability of a new product release (V.U) | availability date + 2 years | availability date + 5 years |
| release of next product patch | ∅ | ∅ |
| release of new product update (U→U+1) | release date + 1 year 2 3 | release date + 4 years 2 4 |
| release of new product version (V→V+1) | release date + 1 year 2 5 | release date + 4 years 2 4 |
Legend
- ∅ No change in discontinuance nor obsolescence dates.
- 1 Obsolescence dates can be brought forward due to third party vendor-specific support terms.
- 2 Product availability and product support are extended by migrating to the new product release. For customer availability (CA), product availability and product support are extended only for that customer after migration to the latest version.
- 3 Capacity upgrade and new product orders are delivered with the latest product update (i.e. latest V.U).
- 4 Fixes are delivered on latest product update (i.e. latest V.U). Once the discontinuance of a product version is announced, its obsolescence date does not change (i.e. obsolescence date is fixed by the discontinuance announcement).
- 5 Availability of a new product version triggers the discontinuance of the previous product version (refer to discontinuance event). Although the latest product version is proposed by default, capacity upgrade and new product order can be delivered with the previous product version (on its latest product update) during 1 year.
- 6 Support of obsolete product versions is possible through an extended support contract, with a customized service level agreement.
Explanations
- Discontinuance or "end of sales" date is when a given version of a product is no longer commercially available (i.e. orderable) from Buzzinbees.
- Obsolescence or "end of support" date is when a given version of a product is no longer supported with Buzzinbees standard service level agreement (SLA).
- Availability of a product can be "general" (i.e. general availability - GA) or "customer specific" (i.e. customer availability - CA):
- GA means a product available for all Buzzinbees customers,
- CA means a product available for a specific customer, qualified for specific use cases.
- When a product is discontinued and still supported, Buzzinbees:
- proposes a migration plan including how to manage new functionality requests,
- answers questions about product set-up, usage and configuration.
Third party vendor-specific support terms
Our end-customers must remain on a supported environment to receive technical support. If a vendor retires support for its product, our customers will be required to upgrade to a supported environment (hardware, operating systems...) to continue receiving technical support services from Buzzinbees.
Version numbering
3-level numbering: version.update-patch (V.U-P)
| level | definition |
|---|---|
| version number | - new functionality that brings additional value for customers. These new functionalities are charged either through new prices for base and capacity part numbers or through specific part numbers - any product enhancement that can't be charged through specific part numbers (e.g. major performance improvement) |
| update number | - maintenance release. Maintenance releases contain all bug fixes done since the previous update release (i.e. cumulative patch version,) that are validated for all customers and use cases - small enhancements, bringing no "significant" value (e.g. product robustness) - new functionality, protected by a specific license key (e.g. Bee-SOON EIR feature on top of Bee-SOON ADD) |
| patch number | - specific bug fix for a customer. Hence this product release is validated only for a customer, even though it contains all previous patches (aka cumulative patch) |
Note
- As updates come with guaranteed backward compatibility, only the latest update of a given version can be ordered.
- Patches specific to a customer are only delivered on the latest update
- Discontinuance (aka end of sale) for a product version is announced one year ahead with a migration plan. Typical migration plans are based on the availability of a new product version. During this migration timeline, both the new and the previous versions can be ordered.
Release numbering properties
| description | new version # | new update # | new patch # |
|---|---|---|---|
| new functionality with specific licensing | √ | √ | ∅ |
| new functionality included in base license | √ | ∅ | ∅ |
| backward compatibility and same product behavior | ∅ 1 | √ | √ |
| bug fix specific to a customer | ∅ 2 | ∅ 2 | √ |
| maintenance release | ∅ | √ | ∅ |
| sustaining release (support of new h/w or o/s platform) | √ 3 | √ 3 | ∅ |
| free of charge with support contract | ∅ | √ 4 | √ |
| free of charge with RTNV contract (support is mandatory with RTNV) | √ | √ | √ |
Legend
- √ A release which increments this number meets the described requirement or contains the described enhancement.
- ∅ Can't be delivered in a release that increments this number.
- 1 Backward compatibility and same product behavior are not guaranteed.
- 2 New version or update include all previous bug fixes found in that product.
- 3 Number increment is not mandatory when existing product supports the new platform without any code change.
- 4 New functionality with specific licensing is not included.