Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

This is a draft, unapproved document being worked on by the EdgeX LTS Tiger Team.  It is work in progress and not official policy.  The original LTS policy is under review in anticipation of the Jakarta release (fall 2021) which is likely to be named the first EdgeX LTS.

STS is an abbreviation for “Short Term Support”.

LTS is an abbreviation for “Long Term Support”.

EdgeX Release Cadence

EdgeX Foundry plans to produce and release a new named version (like Delhi, Edinburgh, Fuji, etc.) of EdgeX roughly every six (6) months.  Named versions will also have a version number in the form of X.Y (X is the major release number and Y is the minor release number; example 1.0 or 2.1).  Depending on the features and compatibility with the prior release, the named release may be a major or minor release (see releases, versions and patches).  The EdgeX TSC decides the nature (major or minor release) and final contents of each release approximately six months in advance of the release.

Note, EdgeX named releases incorporate core services, supporting services, and security services.  The SDKs, app services and device services release independently, they must stay in sync on major versions and typically release in close proximity to the named released services.

Definition of Support

Support, by the EdgeX community, is defined as:

  • Community members best effort and development priority to fix major flaws (as determined by the project’s appropriate working group chairperson(s) in consultation with the release manager) as soon as possible. Major flaws are critical or high bugs as defined above.
  • Availability of the source code, test code and artifacts, and program artifacts such as micro service executables, shared libraries, container images (Docker), packages (snaps), etc. through the support period that were created and made available at the time of the release (see what is included in support below)
  • Availability of the platform documentation through the support period that were created to explain and operate the release and all associated artifacts that were made available at the time of the release (see what is included in support below).

EdgeX Short Term Support (STS)

STS is provided for with each release (typically a release is made every 6 months). Work group chairpersons determine which issues (critical, high, medium or low) in the latest release must be addressed (in consultation with the release czar and with approval of the TSC) and may release a minor or patch release to address issues for that release before the next release.  Once a new release is made, the old release STS (for any release that is not designated as an LTS release) ends and no further work / support is made on the old release.

EdgeX LTS

The TSC officially designates a release for LTS based on the needs of the community and the stability of the release.  At the point of an LTS designated release, the TSC will define the support period for that release (typically 24 months but may be adjusted by the TSC).  At least six months prior to the end of the LTS term, the TSC will meet and determine whether the support for an LTS release will be extended.  Support may be extended, for example, in order to provide sufficient overlap with an anticipated new LTS release to allow adopters to transition.

When an LTS is released, new branches are created for the LTS release code allowing its independent maintenance and allowing development of EdgeX to continue on the projects' main branches.

Changes to an LTS

No new functionality will be added to an LTS release.  Only significant security and bug fixes will be added to the LTS.  Significant is defined as high or critical issues per the following EdgeX definitions of issues and bugs:

  • Critical - bug causes the system or service to crash and there is no work around for the function; or the issue is deemed a critical level CVE (per CVSS)
  • High - bug for a feature/function does not work and there is no work around for the function; or the issue is deemed a high-level CVE
  • Medium - bug makes it more difficult to complete a function/task but there is a work around for the issue; or the issue is deemed a medium level CVE
  • Low - bug is cosmetic in nature (examples: a misspelling in a UI or sort order error) and does not impede any function or task; or the issue is deemed a low-level CVE.

Work group chairpersons, in consultation with the release czar, will coordinate work on LTS bug fixes and make determinations on new LTS minor releases or patches.  Disagreements on whether a bug fix should be made on an LTS release and/or on the need for a new LTS minor release or patch will be adjudicated by the EdgeX TSC.  While a patch release update to the LTS release is typically reserved for critical or high issues/bugs, the TSC reserves the right to make a patch release on-demand for any bug/security issue discovered.

When the EdgeX community creates a new minor release that stems from an LTS release as part of its normal 6-month cadence, the new dot release is not an LTS release by default.  The EdgeX TSC can designate any release LTS, but a release is not LTS by default extension of the prior release.  So, for example, if version 2.1 is designated an LTS release, version 2.2 created as part of the normal cadence six months after 2.1 is not automatically an LTS by extension.

Support of an LTS Release

An LTS release is meant to be a stable release for which organizations typically base products and for which the EdgeX community offers “support” as defined above.

Additional professional support (LTS or STS) including guaranteed service-level agreements and commercial support coverage may be provided by other members of the EdgeX Foundry community.  The EdgeX Foundry project and Linux Foundation can provide connections to providers as necessary.

Recommended Use of EdgeX Releases

The community (developers) is encouraged to use the latest EdgeX development releases when creating new products and services.   Businesses and organizations (adopters) are encouraged to use the latest LTS release when releasing (for production settings) their own products and services that are built on top of or including EdgeX.  The EdgeX Foundry community makes announcements on its website about upcoming release end of life LTS events.  Users are encouraged to watch the EdgeX Foundry web site and Wiki for support notifications.  The Releases page of the EdgeX Wiki will always provide the latest status and news regarding EdgeX LTS releases.

What’s covered in an LTS Release?

The EdgeX community will maintain copies of the release materials in the list below in order to address issues and provide LTS minor and patch releases.

  • The EdgeX core and supporting services.
  • The EdgeX SDKs (application and device service SDKs at the time of this writing)
  • The application services created for that release
  • The device services created for that release
  • The documentation (if there is a need to clarify a critical/high flaw)
  • The release Docker Compose files (and associated Compose Builder tool)
  • Deployment artifacts to include the Docker images, Snaps

Work such as examples (in the edgex-examples repository) will typically not be covered under LTS.

The items covered under LTS will be itemized in the release notes by the TSC when an LTS is designated. The TSC reserves the right to exclude some elements from LTS when designating an LTS.  As mentioned previously in this document, the support period for the LTS and all of its elements will be stipulated at the time of LTS designation and will also mentioned in the release notes for the release.

LTS Rebuilds

Go Based Projects

Archiving Go Dependencies

  • At the time of the release, Go module dependencies will be exported and committed to the repository using the go mod vendor command. This will allow the Go dependencies to be updated and the Go binary to be rebuilt.
  • After the initial commit of go dependencies into the repository, if there are any changes to dependencies, developers should commit those back into the repository
  • Jenkins build scripts may need to be updated to use local vendor dependencies

C Based Projects

  • At the time of release, we will snapshot the C based docker builds images and store them in Nexus3. Base build images will be project specific and baked with the needed dependencies to compile the source code.
  • These images can then be used as part of the Jenkins pipeline or for local development by overriding the --build-arg BASE when building the source code

Examples:

Rebuilding Docker Images

All EdgeX docker images take advantage of a parameterized FROM. This allows us to easily change the base image when we build docker images. We can take advantage of this to build base images containing all build dependencies needed for rebuilding.

  • All base images used in the build pipelines should be archived in the Nexus3 release repository and the Jenkins pipeline build scripts should be updated to use said Nexus3 repository.

Example Base Images:



  • No labels