End-of-Software Maintenance

[santosomar]

This is a follow up of #13

Let's define each element and work on their definitions in separate GitHub issues. This issue will focus on defining:

End-of-Software Maintenance

[tschmidtb51]

@santosomar: I think those are two distinct things (as mentioned in #13 (comment))

1. End of Software Maintenance: No bugfixes, no new feature
2. End of Security vulnerability Support: no more security fixes

This also reflects what is currently done by many open source projects (not backporting new features, but keeping security up-to-date for a while) and commercial products (e.g. Windows 10)

[santosomar]

You are right, @tschmidtb51 . Some companies use the same milestone and not others. I am separating both of them and creating a new issue.

[santosomar]

I created #32 for the "End of vulnerability support"

[santosomar]

Potential Definition

End-of-Software Maintenance (EOSM) marks the date when a vendor or maintainer ceases to provide maintenance updates for a specific software product. Maintenance updates typically include minor bug fixes, performance improvements, and minor feature enhancements. After the EOSM date, the software will no longer receive these updates, although security patches and critical fixes may still be provided until the End-of-Security Vulnerability Support (EOSVS) date.

Example:

Consider a project management software called "TaskMaster" developed by SoftCorp. SoftCorp announces that the End-of-Software Maintenance for TaskMaster version 2.5 will be on March 31, 2024. After this date, SoftCorp will no longer provide maintenance updates such as bug fixes or minor enhancements for TaskMaster 2.5. However, security patches will still be issued until the End-of-Security Vulnerability Support date of March 31, 2025. Users are advised to upgrade to TaskMaster version 3.0 to continue receiving full maintenance and support.

[fjscao]

"a specific software product" needs to be clarified. There are two categories: the product or <product, version>. In many cases, <product, version> is the case.

[p-rog]

@santosomar based on our last discussion, shoudn't we rename this issue to "End-of-Maintenance" ?
I doubt if we need to distinguish "Software" and "Hardware" here.

We can leave it as is and discuss it when we will have the official definition proposal.

[p-rog]

Hello Team,

as discussed in the last meeting, @thschaffr and I worked on this End-of-Maintenance definition.
We call it End-of-Maintenance, because similarly to the End-of-Life (EoL) and End-of-Sales (EoS) definitions, our proposal covers software, hardware and any other type of deliverables, like it is defined in the Product Lifecycle definition (see #35 (comment)).

End-of-Maintenance definition proposal:

The End-of-Maintenance (EoM) indicates the phase (start date and end date) when a particular product (or the product version/release) is in scope for a predefined maintenance level. The scope of maintenance may be defined by the vendor as feature updates, bug updates or security updates (including vulnerabilities patches). Product vendors can define many maintenance support levels - with different scopes - that may be clearly defined in the vendor’s product lifecycle model. After this date users or customers should no longer expect any further updates provided for this support phase.

Important note 1:
This definition is universal and we assume here that a mandatory it will be to provide the scope of this lifecycle stage, like: new features, improvements, bugs updates, security updates, vulnerabilities updates.
We can define the most common scope items and optionally there could be scope definition helpers, that vendor can use to explain precisely what the mentioned scope exactly means.
By doing this, we don't need to specify separate, dedicated lifecycle types for "End-of-Security Vulnerability Support" (#32) or even "End of Extended Support" (#31). Vendors (based on the vendor definition from #37) will be able to create many End-of-Maintenance (EoM) type lifecycle stages and in the scope specify what exactly is in scope of this specific maintenance.

Important note 2:
This support model should have the start date as an optional field, because like it is mentioned in the Product Lifecycle definition, in some use cases one product could be at the same time in many maintenance support phases. Having only last date disallows having ranges overlapping.

We are looking forward to the input from the TC.
Thank you!

[p-rog]

Like we discussed and what is documented in #38, in the OpenEoX standard we want to focus, at least for now, on the end date of specific support phase (milestone).

Hence here is an update to the End-of-Maintenance definition proposal:

The End-of-Maintenance (EoM) indicates the last day when a particular product (or the product version/release) is in scope for a predefined maintenance level. The scope of maintenance may be defined by the vendor as feature updates, bug updates or security updates (including vulnerabilities patches). Product vendors can define many maintenance support levels - with different scopes - that may be clearly defined in the vendor’s product lifecycle model. After this date users or customers should no longer expect any further updates provided for this support phase.

This definition is universal and we assume here that it will be mandatory to provide the scope of this lifecycle stage (mandatory scope field), like: new features, improvements, bugs updates, security updates, vulnerabilities updates. In the OpenEoX standard we can define the most common scope items, that vendor can use to explain precisely what the mentioned scope exactly means.