Date 1 - 1 of 1
ODL release model
|1 - 1 of 1|
I personally found very interesting the ODL release model conversation we held in DDF.
In particular I would like to see if the current project classification and release model: MRI, MSI, SM could evolve to something simpler like it was proposed this morning:
1) Platform projects (upstream):
- Composition: Typically critical ODL projects consumed by others projects.
- Release schedule: Release before the rest of the projects.
- Requirements: Provide a release version and release notes for every release milestone.
2) Plugins/Apps projects (downstream):
- Composition: Typically not critical projects consuming the ODL Platform.
- Release schedule: Release after the platform.
- Requirements: Projects can opt-in or opt-out for a given release. If they opt-in they have to provide a release version and release notes before the release milestone.
The above covers few features but it could be more.
In general I can see that if we take this classification/release model, we could effectively:
- Remove Autorelease and Managed distribution.
- Save work in Platform projects, they do not have to to baby-sit AR projects.
- Since work (like energy) does not vanishes, only moves, I believe the Plugins/Apps projects will have to work more on the platform updates + infra changes (branch, bump, jenkins updates, etc). Basically the same an SM project does today.
- Today Platform projects have to coordinate themselves to produce a release, the same is expect to happen in Plugin/Apps projects when there are dependencies between them.
- Since AR is removed, we might need some extra tooling to check version alignment before a release. Maybe we can do this in the Common distribution.
Overall, I like the model but before we can take it for a TSC approve, we need to:
- Proper define the 2 project groups (requirements, etc)
- Select which projects are Platform today (the rest are Plugins/Apps).
- Define the process to move a project from 1 group to another.
- Create release schedule for the 2 groups.
- Analyze changes in CSIT: Most likely we will need Plugins/Apps projects to generate their own karaf distribution to test patches and stable branches.
Any other thoughts?
|1 - 1 of 1|