ONOS Core Incubator
50 views
Skip to first unread message
Thomas Vachuska
May 14, 2015, 10:24:33 PM5/14/15
to onos-dev, Thomas Vachuska
Hi everyone,
This is a heads-up that the ONOS core ‘exp’ code area has been renamed to ‘incubator’, to better reflect the nature of the modules within. This change is currently under review, but will go in shortly.
The intent is to allow contributors to add to the API and to the Core implementations in a creative way and on their own time-line while making their interfaces/API exempt from the deprecation policy, meaning that the API can change from release to release.
The idea is to set up onos-incubator-api and onos-incubator-net|store modules, with a corresponding Java package namespace org.onosproject.incubator. This could be then viewed as a sandbox or a nursery of future core code. This will allow physical separation of such code for certain production environments, but at the same time will allow experimenters to treat this as part of the ONOS code.
This is in addition to the existing capability where apps can expose their own APIs that can be consumed by other parts of the app, or by other apps.
The following depicts the module dependencies. Note that no part of the onos-core should depend on onos-incubator-api or onos-app-*.
This is a heads-up that the ONOS core ‘exp’ code area has been renamed to ‘incubator’, to better reflect the nature of the modules within. This change is currently under review, but will go in shortly.
The intent is to allow contributors to add to the API and to the Core implementations in a creative way and on their own time-line while making their interfaces/API exempt from the deprecation policy, meaning that the API can change from release to release.
The idea is to set up onos-incubator-api and onos-incubator-net|store modules, with a corresponding Java package namespace org.onosproject.incubator. This could be then viewed as a sandbox or a nursery of future core code. This will allow physical separation of such code for certain production environments, but at the same time will allow experimenters to treat this as part of the ONOS code.
This is in addition to the existing capability where apps can expose their own APIs that can be consumed by other parts of the app, or by other apps.
The following depicts the module dependencies. Note that no part of the onos-core should depend on onos-incubator-api or onos-app-*.
For example, the NetworkConfigService subsystem will release in Cardinal in this area and once we’ve let the interface settle, we will move it out of the incubation area. The goal for the code in the incubator is to remain there for no more than two releases; typically only one release.
Thomas
Reply all
Reply to author
Forward
0 new messages