The EdgeX Technical Steering Committee (TSC) has established a bi-annual release roadmap to provide a product-quality open source foundation for interoperable commercial differentiation with increasing enablement of real-time fog computing use cases. In order to provide EdgeX consumers with a predictable foundation to base their commercial offerings on it is the goal of the TSC to outline key release themes at least 12 months in advance and to plan features to be delivered in a given release 6 months in advance. As with any open source software project, delivery of planned features is based on priority and available developer bandwidth.

Release cadence (as of January 2018 TSC Face-to-face meeting) is bi-annually, with targets of April and October as release months

Refer to the each page for target functionality by EdgeX release:

'Barcelona': October 2017

'California': ~June 2018

'Delhi': ~October 2018

'Edinburgh': ~ April 2019

'Fuji': ~ October 2019

'Geneva': ~ April 2020

We welcome the community to help shape the overall EdgeX roadmap through participation in the working groups and to accelerate delivery of desired functionality by making code contributions to the project.

Overall EdgeX Foundry Project Vision

Below are general notes on overall EdgeX project needs and vision (big and small). This list will evolve over time and specific features will be slotted into the official roadmap by the TSC (see the individual release roadmap lists). Initial prioritization will be on enabling commercial offers for Industrial IoT deployments with a stable, product-quality foundation and over time focus will be increased on real-time fog computing use cases. This list should serve as guiding instructions to contributors at all levels of the project and we welcome experimentation on future needs in addition to contributions to the primary project roadmap.

General Code Clean Up

The following list constitutes known areas for ongoing clean up within the EdgeX Foundry code base. This is not a bug list, rather a list of more general design flaws, systemic implementation issues, coding practices, etc.

A base service class is needed for all microservices (the base class could potentially include security and sys management APIs)