Versions Compared

Key

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

Code Freeze:  May 28, 2019

Release:  June 20, 2019 (ver 1.0.1 - July 22, 2019)

Table of Contents

The Edinburgh release is expected to be version 1.0 and a significant milestone in the EdgeX progression.  It will be made available shortly after the 2nd anniversary of the project and will signal EdgeX is fit for purpose and ready for wide use/dissemination and long term support in edge/IoT solutions.  The Edinburgh release will focus on an improved user on-boarding experience, support for binary data, better database/persistence abstraction (for future database replacements), testing dashboard and performance testing, the initial implementation of an eventual export service replacement (application services) in addition to additional security and system management needs that were started in 2018.

...

  • Improved on-boarding for EdgeX users.  This includes documentation, tutorials, dev kits, and other material to make getting, using and understanding EdgeX easier.
  • EdgeX will support the ingestion, use and export of binary data in CBOR format. Device Services will be allowed to send binary data as part of the Event/Reading packages. Core and Export Services will be adapted to handle, persist, and route/send binary data as it does integer, float, and string data today. Incorporation of binary data will allow custom built local analytics to use the binary data to trigger actuation of devices. https://github.com/edgexfoundry/edgex-go/issues/820
  • EdgeX database-using services (Core Data, Metadata, Export Client, Logging, Notifications, and Scheduling) will be refactored to be more loosely coupled to the persistence mechanism (currently MongoDB). This will ease the use of alternative persistent stores and technology (such as streaming) in future implementations and even allow the project to select alternate or additional reference implementation databases in future releases. https://github.com/edgexfoundry/edgex-go/issues/821
  • The current Export Services, while functional, create scalability issues. The current EdgeX capability relies on the Export Services to know and understand all possible endpoint distribution mechanisms and transformation capability necessary to support all clients – even if the use case requires only a single, simple client need. As the number and type of EdgeX north side clients expands, this service will be too big and complex to support the north side needs. The initial and simple Application Services in the Edinburgh release will be designed and implemented to support smaller, more tailored exportation needs. These services will contain just the functionality (filtering, transformation, enrichment, etc.) needed for a single endpoint. To address multiple endpoints, multiple Application Services will be created. In a way, the Application Services will begin to look more like the south side Device Services – that is functionality dedicated to a particular client protocol and data need. Long term over the course of a number of releases, Application Services will replace EdgeX Export Services as the north side distribution facility.  https://github.com/edgexfoundry/edgex-go/issues/822EdgeX has greatly reduced its memory and file size footprint, and improved the performance of many operations (to include startup time) over the past two releases. An automated performance framework will be implemented for the Edinburgh release to continually check that the performance metrics of EdgeX meet or exceed the expectations of an edge software platform as determined by the community. The current platform performance targets can be found here: https://wiki.edgexfoundry.org/display/FA/California+Release#CaliforniaRelease-TargetPerformancehttps://github.com/edgexfoundry/edgex-go/issues/115
  • Provide many Device Service implementations using the Delhi release provided Go and C DS SDKs. As a target, the Edinburgh release will provide replacement services for the existing Java Modbus, BACNet, BLE, MQTT and SNMP device services. Many additional Device Services are anticipated with the Edinburg release. https://github.com/edgexfoundry/edgex-go/issues/823

...

  • The Edinburgh release will feature a new service type called Application Services as indicated in the major themes and objectives of this release that will be the eventual replacement for Export Services.  Application Services may include experimentation in technology such as GoKit and Function-as-a-service (aka serverless compute) to help implement. https://github.com/edgexfoundry/edgex-go/issues/822Implementation of a lightweight rules engine option or other “edge analytic” capability to replace the Java, Drools-based rules engine currently serving as the EdgeX reference implementation.  This is the last of the Java micro services still used in EdgeX. https://github.com/edgexfoundry/edgex-go/issues/99

Core Working Group Tasks and Notes

...

  • Given Edinburgh will be EdgeX version 1.0, the EdgeX community will adopt a release, support and version strategy to provide guidance around backward compatibility to the development and user community.  Additionally, the community will define a long term support policy that defines the communities intended support of the EdgeX Foundry platform.
  • EdgeX has used Rocket Chat as the message channel for contributor and user information exchange since the project’s inception.  With the upcoming release, the community is going to switch to Slack – a more widely used and accepted form of developer communications.
  • With the Edinburgh release, the community has resolved to adopt a “Release Manager” to monitor, guide, document and manage each release.  The Release Manager role will rotate through organizations like Dell, IoTech, Intel, and Canonical.  Michael Hall will lead efforts to define the duties of the role and Keith Steele (or TSC chair) will coordinate the rotation of the role to the larger supporting organizations.
  • EdgeX will have and advertise its support contract/policy to the world with the Edinburgh release.
  • The TestQA and DevOps working groups will meet simultaneously in order to stream line efforts that are often intertwined.


Release Summary Deck