SDK version lifespan

The eForms SDK encodes the eForms specification in a machine-readable format. As the business domain of public procurement evolves over time, the eForms specification is also updated to incorporate the necessary changes. This evolution is reflected in the SDK versions, which permit us to bundle together all the artifacts necessary to interpret notices that have been created in different points in time (and thus under a possibly different regulatory framework).

When your application creates an XML notice, it includes a cbc:CustomizationID element that indicates the version of the SDK that was used to create the notice. This permits other applications to interpret the notice correctly, by using the corresponding version of the SDK.

SDK Versioning in a nutshell

SDK versions are indicated using three numbers: major.minor.patch. The major version number is incremented only when the new SDK introduces fundamental changes. The minor is incremented when the updated SDK has an impact on notice validation. Finally, the patch indicates an incremental update that does not affect notice validation. When we refer to an SDK version without specifying the patch number, the latest patch of that version is implied. For details see the SDK Versioning page.

New versions of the SDK are released periodically, not only to accommodate regulatory changes, but also to correct and enrich the existing metadata. To maintain an overall consistency of the data collected through eForms notices, in terms of completeness and quality, it is in the general interest of the public procurement community to ensure that outdated versions of the eForms specification are withdrawn from active use for applications that create eForms notices.

To encourage the timely adoption of the most recent version of the eForms specification, the Publications Office has established the following policy for the withdrawal of outdated versions of the SDK.

The policy is based on the notion that every SDK version has a predefined lifespan which starts when the TED Central Validation Service (TEDCVS) starts accepting notices created using the new version (right after its release), and ends after a predefined period of activity has elapsed (at which point, TEDCVS will automatically stop accepting any further notices created using that version of the SDK). An SDK version is said to be "active" during the period that TEDCVS accepts notices based on it.

Terminology

SDK release date

The date when a new version of the SDK is released.

SDK expiry date

The date beyond which an SDK version is no longer accepted by the TED Central Validation Service. This date is initially set for every SDK version to twelve (12) months after its release date. The expiry date of an SDK version may be extended beyond the standard lifespan of twelve (12) months (see "SDK extended lifespan" below).

Active SDK

A version of the SDK is said to be "active" during the period that TEDCVS accepts notices based on it. This period is defined by the SDK release date and the SDK expiry date.

SDK standard lifespan

The standard lifespan of an SDK version is the first twelve (12) months after its release date.

SDK extended lifespan

To accommodate the needs of eSenders, the Publications Office may decide to extend the lifespan of an SDK version beyond its standard length. If the lifespan of an SDK version is extended beyond the standard lifespan of twelve (12) months, the version is said to be in its "extended lifespan".

Support and updates for active SDK versions

The Publications Office provides support only for active SDK versions through its Helpdesk and GitHub discussions. Priority is given to SDK versions that are in their standard lifespan.

The Publications Office also updates active SDK versions by releasing patches that correct and improve the provided metadata as needed. However, to conserve resources, patches are provided only during the standard lifespan of active SDK versions. SDK versions that are in their extended lifespan will only be patched under exceptional circumstances to address critical issues.

List of active SDK versions

The table below indicates the end of the standard and extended lifespan for the SDK versions that are currently active.

To accommodate the needs of eSenders during the current transitional period, the Publications Office has decided to extend the lifespan of the SDK versions expiring in 2024. This is an exceptional measure in view of the efforts of eSenders to stabilise their processes for incorporating updates to the eForms specification into their applications.
The table below is updated manually and may not be always accurate. The information provided by the TED API should always be consulted as the single source of truth. For more details see Getting active SDK versions through TED API below.
Table 1. Active versions of the eForms SDK
SDK Version End of standard lifespan End of extended lifespan

1.3

31 December 2023

31 January 2024

1.4

31 December 2023

31 January 2024

1.5

31 December 2023

31 January 2024

1.6

6 March 2024

31 July 2024

1.7

11 May 2024

30 September 2024

1.8

26 July 2024

30 November 2024

1.9

9 October 2024

28 February 2025

1.10

1 December 2024

28 February 2025

The Preview environment has the same active range as the Production environment.

Getting active SDK versions through TED API

TED API provides information on the set of active SDK versions in JSON format through the version-range operation of the Validation API.

{
  "updatedOn": "2022-07-20T15:16:00", (1)
  "activeVersionRange": {
    "earliest": { (2)
      "before": "1.0", (3)
      "after": "1.1", (4)
      "switchDate": "2022-10-31T01:00:00+02:00" (5)
    },
    "latest": { (6)
      "before": "1.5",
      "after": "1.6",
      "switchDate": "2023-03-08T01:00:00+02:00"
    },
    "excluded": { (7)
      "before": [ "1.2" ],
      "after": [ "1.2", "1.3" ],
      "switchDate": "2023-01-10T01:00:00+02:00"
    }
  }
}
1 Date and time when the information in this file was last updated.
2 Information on lowest active version.
3 Lowest active version before the switch date.
4 Lowest active version after the switch date.
5 Date and time when the effective value goes from what’s indicated in before to what’s indicated in after.
6 Information on highest active version.
7 List of versions excluded from the set of active versions.

For the earliest, latest and excluded versions, changes can be planned: if the current date and time is before "switchDate", then the value in "before" must be used, otherwise the value in "after" must be used.

So for the example above:

  • on 2022-10-30, the active versions are: 1.0, 1.1, 1.3, 1.4, 1.5 (1.0 to 1.5; version 1.2 is excluded)

  • on 2022-11-01, the active versions are: 1.1, 1.3, 1.4, 1.5 (1.1 to 1.5; version 1.2 is excluded)

  • on 2023-01-11, the active versions are: 1.1, 1.4, 1.5 (1.1 to 1.5; versions 1.2 and 1.3 are excluded)

  • on 2023-03-09, the active versions are: 1.1, 1.4, 1.5, 1.6 (1.1 to 1.6; versions 1.2 and 1.3 are excluded)