OpenDaylight branching analysisStephen Kitt, Robert Varga– 2016-01-11

2

Intro• Based on https://

lists.opendaylight.org/pipermail/release/2015-October/004147.html• Analysis at https://wiki.opendaylight.org/view/New_workflow_proposal

3

Basic assumptions• All projects divided into three groups

• Offsets or kernel/protocols/apps• How projects are grouped is not relevant

• Each group has its own development cycle• Per-group ‘autorelease’ setup

• Inter-group dependencies are strictly on released artifacts• Intra-group dependencies are strictly on SNAPSHOT artifacts

4

Simplistic* three-project illustrationYangtools master

Yangtools stable/boronYT release

YT release propagation

Mdsal master

MDSAL release

Controller stable/boron

Controller masterCTRL release

YT+MDSAL release propagation

*) Does not account for how the autorelease looks

Per-group autorelease contents• Upstream groups’ artifacts on their released version

• Upstream delivers fixes via stable releases

• This group’s artifacts on SNAPSHOTs• Downstream artifacts on SNAPSHOTs

• Previous version + any modifications to make integration work• ‘integration branch’• Never actually released

The ‘integration branch’• Actually a per-group collection of per-project branches• Created for each new release cycle using latest release artifacts• Contains fixes to make the component work with upstream

development• “Owned” by its group projects

• Similar rules to autorelease participation• Upstream can decide to drop a downstream project to get unblocked

• Retired when the group performs a release• Available for cherry-picks and merges into downstream

Risks• Release artifact propagation occurs between groups

• Propagation blocked until all projects in downstream group complete• … or are thrown out of the release, which affects their downstream

• What is the integration window?• Issues reported by downstream has to be prioritized• If ‘integration-critical’ bugs are raised, upstream dev cycle is interrupted• May be reasonably predictable

• How important is upstream?• Issues encountered by upstream integration need to be analyzed/fixed• Disrupts downstream dev cycle to analyze bugs• Project dropped from integration branch in limbo until fixed, along with all its consumers

Mitigation• Smaller groups

• Faster integration• Less functionality skew

• Semantic versioning• ‘Free’ minor upgrades

• Faster releases• Less ‘delta’ between integrations

• Different development workflows?