Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 , which is 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 transitionby default.  Support may be extended at TSC discretion.

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 major 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:

...

Work group chairpersons, in consultation with the release czar, will coordinate work on LTS bug fixes and make determinations on new LTS minor patch 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 patch 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 The next major/minor release that stems from follows after an LTS release as part of its normal 6-month cadence, the new dot release is not an LTS release by defaultis by definition an STS release.  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.

...

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.following EdgeX components are covered by this LTS policy

  • The EdgeX core and supporting services.
  • The latest compatible major/minor releases of EdgeX SDKs (application and device service SDKs at the time of this writing)
  • The latest compatible major/minor releases of all reference application services created for that release
  • The latest compatible major/minor releases of all reference 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

...

  • 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 this 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.

...