docs/release-process/managed-release.rst

   1 ***************
   2 Managed Release
   3 ***************
   4
   5 Managed Release Summary
   6 =======================
   7
   8 The Managed Release Process will facilitate timely, stable OpenDaylight
   9 releases by allowing the release team to focus on closely managing a small set
  10 of core OpenDaylight projects while not imposing undue requirements on projects
  11 that prefer more autonomy.
  12
  13 Managed Release Goals
  14 =====================
  15
  16 Reduce Overhead on Release Team
  17 -------------------------------
  18
  19 The Managed Release Model will allow the release team to focus their efforts
  20 on a smaller set of more stable, more responsive projects.
  21
  22 Reduce Overhead on Projects
  23 ---------------------------
  24
  25 The Managed Release Model will reduce the overhead both on projects taking
  26 part in the Managed Release and Unmanaged Projects.
  27
  28 Managed Projects will have fewer, smaller checkpoints consisting of only
  29 information that is maximally helpful for driving the release process. Much of
  30 the information collected at checkpoints will be automatically scraped,
  31 requiring minimal to no effort from projects. Additionally, Managed Release
  32 projects should have a more stable development environment, as the projects
  33 that can break the jobs they depend on will be a smaller set, more stable and
  34 more responsive.
  35
  36 Projects that are Unmanaged will have less overhead and reporting. They will
  37 be free to develop in their own way, providing their artifacts to include in
  38 the final release or choosing to release on their own schedule. They will not
  39 be required to submit any checkpoints and will not be expected to work closely
  40 with the rest of the OpenDaylight community to resolve breakages.
  41
  42 Enable Timely Releases
  43 ----------------------
  44
  45 The Managed Release Process will reduce the set of projects that must
  46 simultaneously become stable at release time. The release and test teams will
  47 be able to focus on orchestrating a quality release for a smaller set of more
  48 stable, more responsive projects. The release team will also have greater
  49 latitude to step in and help projects that are required for dependency reasons
  50 but may not have a large set of active contributors.
  51
  52 Managed Projects
  53 ================
  54
  55 Managed Projects Summary
  56 ========================
  57
  58 Managed Projects are either required by most applications for dependency
  59 reasons or are mature, stable, responsive projects that are consistently able
  60 to take part in releases without jeopardizing them. Managed Projects will
  61 receive additional support from the test and release teams to further their
  62 stability and make sure OpenDaylight releases go out on-time. To enable this
  63 extra support, Managed Projects will be given less autonomy than OpenDaylight
  64 projects have historically been granted.
  65
  66 Managed Projects for Dependency Reasons
  67 ---------------------------------------
  68
  69 Some projects are required by almost all other OpenDaylight projects. These
  70 projects must be in the Managed Release for it to support almost every
  71 OpenDaylight use case. Such projects will not have a choice about being in the
  72 Managed Release, the TSC will decide they are critical to the OpenDaylight
  73 platform and include them. They may not always meet the requirements that
  74 would normally be imposed on projects that wish to join the Managed Release.
  75 Since they cannot be kicked out of the release, the TSC, test and release teams
  76 will do their best to help them meet the Managed Release Requirements. This
  77 may involve giving Linux Foundation staff temporary committer rights to merge
  78 patches on behalf of unresponsive projects, or appointing committers if
  79 projects continue to remain unresponsive. The TSC will strive to work with
  80 projects and member companies to proactively keep projects healthy and find
  81 active contributors who can become committers in the normal way without the
  82 need to appoint them in times of crisis.
  83
  84 Managed Release Integrated Projects
  85 -----------------------------------
  86
  87 Some Managed Projects may decide to release on their own, not as a part of the
  88 Simultaneous Release with Snapshot Integrated Projects. Such Release Integrated
  89 projects will still be subject to Managed Release Requirements, but will need
  90 to follow a different release process.
  91
  92 For implementation reasons, the projects that are able to release independently
  93 must depend only on other projects that release independently. Therefore the
  94 Release Integrated Projects will form a tree starting from odlparent. Currently
  95 odlparent and yangtools are the only Release Integrated Projects, but others
  96 may join them in the future.
  97
  98 Requirements for Managed Projects
  99 ---------------------------------
 100
 101 Healthy Community
 102 +++++++++++++++++
 103
 104 Managed Projects should strive to have a healthy community.
 105
 106 Responsiveness
 107 ##############
 108
 109 Managed Projects should be responsive over email, IRC, Gerrit, Jira and in
 110 regular meetings.
 111
 112 All committers should be subscribed to their project's mailing list and the
 113 release mailing list.
 114
 115 For the following particularly time-sensitive events, an appropriate response
 116 is expected within two business days.
 117
 118 * RC or SR candidate feedback.
 119 * Major disruptions to other projects where a Jira weather item was not present
 120   and the pending breakage was not reported to the release mailing list.
 121
 122 If anyone feels that a Managed Project is not responsive, a grievance process
 123 is in place to clearly handle the situation and keep a record for future
 124 consideration by the TSC.
 125
 126 Active Committers
 127 #################
 128
 129 Managed Projects should have sufficient active committers to review
 130 contributions in a timely manner, support potential contributors, keep CSIT
 131 healthy and generally effectively drive the project.
 132
 133 If a project that the TSC deems is critical to the Managed Release is shown to
 134 not have sufficient active committers the TSC may step in and appoint
 135 additional committers. Projects that can be dropped from the Managed Release
 136 will be dropped instead of having additional committers appointed.
 137
 138 Managed Projects should regularly prune their committer list to remove
 139 inactive committers, following the `Committer Removal Process`_.
 140
 141 TSC Attendance
 142 ##############
 143
 144 Managed Projects are required to send a representative to attend TSC meetings.
 145
 146 To facilitate quickly acting on problems identified during TSC meetings,
 147 representatives must be a committer to the project they are representing. A
 148 single person can represent any number of projects.
 149
 150 Representatives will make the following entry into the meeting minutes to
 151 record their presence:
 152
 153 #project <project ID>
 154
 155 TSC minutes will be scraped per-release to gather attendance statistics. If a
 156 project does not provide a representative for at least half of TSC meetings a
 157 grievance will be filed for future consideration.
 158
 159 Checkpoints Submitted On-Time
 160 +++++++++++++++++++++++++++++
 161
 162 Managed Projects must submit information required for checkpoints on-time.
 163 Submissions must be correct and adequate, as judged by the release team and
 164 the TSC. Inadequate or missing submissions will result in a grievance.
 165
 166 Jobs Required for Managed Projects Running
 167 ++++++++++++++++++++++++++++++++++++++++++
 168
 169 Managed Projects are required to have the following jobs running and healthy.
 170
 171 * Distribution check job (voting)
 172 * Validate autorelease job (voting)
 173 * Merge job (non-voting)
 174 * Sonar job (non-voting)
 175 * CLM job (non-voting)
 176
 177 Depend only on Managed Projects
 178 +++++++++++++++++++++++++++++++
 179
 180 Managed Projects should only depend on other Managed Projects.
 181
 182 If a project wants to be Managed but depends on Unmanaged Projects, they
 183 should work with their dependencies to become Managed at the same time or
 184 drop any Unmanaged dependencies.
 185
 186 Documentation
 187 +++++++++++++
 188
 189 Managed Projects are required to produce a user guide, developer guide and
 190 release notes for each release.
 191
 192 CLM
 193 +++
 194
 195 Managed Projects are required to handle CLM (Component Lifecycle Management)
 196 violations in a timely manner.
 197
 198 Managed Release Process
 199 -----------------------
 200
 201 Managed Release Checkpoints
 202 +++++++++++++++++++++++++++
 203
 204 Checkpoints are designed to be mostly automated, to be maximally effective at
 205 driving the release process and to impose as little overhead on projects as
 206 possible.
 207
 208 There will be an initial checkpoint two weeks after the start of the release,
 209 a midway checkpoints one month before code freeze and a final checkpoint at code freeze.
 210
 211 Initial Checkpoint
 212 ##################
 213
 214 An initial checkpoint will be collected two weeks after the start of each
 215 release. The release team will review the information collected and report
 216 it to the TSC at the next TSC meeting.
 217
 218 Projects will need to create the following artifacts:
 219
 220 * High-level, human-readable description of what the project plans to do in this
 221   release. This should be submitted as a Jira **Project Plan** issue against the
 222   TSC project.
 223
 224   * Select your project in the **ODL Project** field
 225
 226   * Select the release version in the **ODL Release** field
 227
 228   * Select the appropriate value in the **ODL Participation** field:
 229     ``SNAPSHOT_Integrated (Managed)`` or ``RELEASE_Integrated (Managed)``
 230
 231   * Select the value ``Initial`` in the **ODL Checkpoint** field
 232
 233   * In the **Summary** field, put something like:
 234     ``Project-X Fluorine Release Plan``
 235
 236   * In the **Description** field, fill in the details of your plan:
 237
 238     .. code-block:: none
 239
 240        This should list a high-level, human-readable summary of what a project
 241        plans to do in a release. It should cover the project's planned major
 242        accomplishments during the release, such as features, bugfixes, scale,
 243        stability or longevity improvements, additional test coverage, better
 244        documentation or other improvements. It may cover challenges the project
 245        is facing and needs help with from other projects, the TSC or the LFN
 246        umbrella. It should be written in a way that makes it amenable to use
 247        for external communication, such as marketing to users or a report to
 248        other LFN projects or the LFN Board.
 249
 250 * If a project is transitioning from Unmanaged to Managed or applying for
 251   the first time into a Managed release, raise a Jira **Project Plan** issue
 252   against the TSC project highlighting the request.
 253
 254   * Select your project in the **ODL Project** field
 255
 256   * Select the release version in the **ODL Release** field
 257
 258   * Select the ``NOT_Integrated (Unmanaged)`` value in the **ODL Participation**
 259     field
 260
 261   * Select the appropriate value in the **ODL New Participation** field:
 262     ``SNAPSHOT_Integrated (Managed)`` or ``RELEASE_Integrated (Managed)``
 263
 264   * In the **Summary** field, put something like:
 265     ``Project-X joining/moving to Managed Release for Fluorine``
 266
 267   * In the **Description** field, fill in the details using the template
 268     below:
 269
 270     .. code-block:: none
 271
 272        Summary
 273        This is an example of a request for a project to move from Unmanaged to
 274        Managed. It should be submitted no later than the start of the release.
 275        The request should make it clear that the requesting project meets all
 276        of the Managed Release Requirements.
 277
 278        Healthy Community
 279        The request should make it clear that the requesting project has a
 280        healthy community. The request may also highlight a history of having a
 281        healthy community.
 282
 283        Responsiveness
 284        The request should make it clear that the requesting project is
 285        responsive over email, IRC, Jira and in regular meetings. All committers
 286        should be subscribed to the project's mailing list and the release
 287        mailing list. The request may also highlight a history of
 288        responsiveness.
 289
 290        Active Committers
 291        The request should make it clear that the requesting project has a
 292        sufficient number of active committers to review contributions in a
 293        timely manner, support potential contributors, keep CSIT healthy and
 294        generally effectively drive the project. The requesting project should
 295        also make it clear that they have pruned any inactive committers. The
 296        request may also highlight a history of having sufficient active
 297        committers and few inactive committers.
 298
 299        TSC Attendance
 300        The request should acknowledge that the requesting project is required
 301        to send a committer to represent the project to at least 50% of TSC
 302        meetings. The request may also highlight a history of sending
 303        representatives to attend TSC meetings.
 304
 305        Checkpoints Submitted On-Time
 306        The request should acknowledge that the requesting project is required
 307        to submit checkpoints on time. The request may also highlight a history
 308        of providing deliverables on time.
 309
 310        Jobs Required for Managed Projects Running
 311        The request should show that the requesting project has the required
 312        jobs for Managed Projects running and healthy. Links should be provided.
 313
 314        Depend only on Managed Projects
 315        The request should show that the requesting project only depends on
 316        Managed Projects.
 317
 318        Documentation
 319        The request should acknowledge that the requesting project is required
 320        to produce a user guide, developer guide and release notes for each
 321        release. The request may also highlight a history of providing quality
 322        documentation.
 323
 324        CLM
 325        The request should acknowledge that the requesting project is required
 326        to handle Component Lifecycle Violations in a timely manner. The request
 327        should show that the project's CLM job is currently healthy. The request
 328        may also show that the project has a history of dealing with CLM
 329        violations in a timely manner.
 330
 331 * If a project is transitioning from Managed to Unmanaged, raise a Jira
 332   **Project Plan** issue against the TSC project highlighting the request.
 333
 334   * Select your project in the **ODL Project** field
 335
 336   * Select the release version in the **ODL Release** field
 337
 338   * Select the appropriate value in the **ODL Participation** field:
 339     ``SNAPSHOT_Integrated (Managed)`` or ``RELEASE_Integrated (Managed)``
 340
 341   * Select the ``NOT_Integrated (Unmanaged)`` value in the
 342     **ODL New Participation** field
 343
 344   * In the **Summary** field, put something like:
 345     ``Project-X Fluorine Joining/Moving to Unmanged for Fluorine``
 346
 347   * In the **Description** field, fill in the details:
 348
 349     .. code-block:: none
 350
 351        This is a request for a project to move from Unmanged to Managed. It
 352        should be submitted no later than the start of the release. The request
 353        does not require any additional information, but it may be helpful for
 354        the requesting project to provide some background and their reasoning.
 355
 356 * Weather items that may impact other projects should be submitted as Jira
 357   issues. For a weather item, raise a Jira **Weather Item** issue against the
 358   TSC project highlighting the details.
 359
 360   * Select your project in the **ODL Project** field
 361
 362   * Select the release version in the **ODL Release** field
 363
 364   * For the **ODL Impacted Projects** field, fill in the impacted projects
 365     using label values - each label value should correspond to the respective
 366     project prefix in Jira, e.g. netvirt is NETVIRT. If all projects are
 367     impacted, use the label value ``ALL``.
 368
 369   * Fill in the expected date of weather event in the **ODL Expected Date**
 370     field
 371
 372   * Select the appropriate value for **ODL Checkpoint** (may skip)
 373
 374   * In the **Summary** field, summarize the weather event
 375
 376   * In the **Description** field, provide the details of the weather event.
 377     Provide as much relevant information as possible.
 378
 379 The remaining artifacts will be automatically scraped:
 380
 381 * Blocker bugs that were raised between the previous code freeze and release.
 382 * Grievances raised against the project during the last release.
 383
 384 Midway Checkpoint
 385 #################
 386
 387 One month before code freeze, a midway checkpoint will be collected. The release team
 388 will review the information collected and report it to the TSC at the next TSC
 389 meeting. All information for midway checkpoint will be automatically collected.
 390
 391 * Open Jira bugs marked as blockers.
 392 * Open Jira issues tracking weather items.
 393 * Statistics about jobs.
 394   * Autorelease failures per-project.
 395   * CLM violations.
 396 * Grievances raised against the project since the last checkpoint.
 397
 398 Since the midway checkpoint is fully automated, the release team may collect
 399 this information more frequently, to provide trends over time.
 400
 401 Final Checkpoint
 402 ################
 403
 404 At 2 weeks after code freeze a final checkpoint will be collected by the release team
 405 and presented to the TSC at the next TSC meeting.
 406
 407 Projects will need to create the following artifacts:
 408
 409 * High-level, human-readable description of what the project did in this
 410   release. This should be submitted as a Jira **Project Plan** issue against
 411   the TSC project. This will be reused for external communication/marketing for
 412   the release.
 413
 414   * Select your project in the **ODL Project** field
 415
 416   * Select the release version in the **ODL Release** field
 417
 418   * Select the appropriate value in the **ODL Participation** field:
 419     ``SNAPSHOT_Integrated (Managed)`` or ``RELEASE_Integrated (Managed)``
 420
 421   * Select the value ``Final`` in the **ODL Checkpoint** field
 422
 423   * In the **Summary** field, put something like:
 424     ``Project-X Fluorine Release details``
 425
 426   * In the **Description** field, fill in the details of your accomplishments:
 427
 428     .. code-block:: none
 429
 430        This should be a high-level, human-readable summary of what a project
 431        did during a release. It should cover the project's major
 432        accomplishments, such as features, bugfixes, scale, stability or
 433        longevity improvements, additional test coverage, better documentation
 434        or other improvements. It may cover challenges the project has faced
 435        and needs help in the future from other projects, the TSC or the LFN
 436        umbrella. It should be written in a way that makes it amenable to use
 437        for external communication, such as marketing to users or a report to
 438        other LFN projects or the LFN Board.
 439
 440   * In the **ODL Gerrit Patch** field, fill in the Gerrit patch URL to your
 441     project release notes
 442
 443 * Release notes, user guide, developer guide submitted to the docs project.
 444
 445 The remaining artifacts will be automatically scraped:
 446
 447 * Open Jira bugs marked as blockers.
 448 * Open Jira issues tracking weather items.
 449 * Statistics about jobs.
 450   * Autorelease failures per-project.
 451 * Statistics about patches.
 452   * Number of patches submitted during the release.
 453   * Number of patches merged during the release.
 454   * Number of reviews per-reviewer.
 455 * Grievances raised against the project since the start of the release.
 456
 457 Managed Release Integrated Release Process
 458 ------------------------------------------
 459
 460 Managed Projects that release independently (Release Integrated Projects),
 461 not as a part of the Simultaneous Release with Snapshot Integrated Projects,
 462 will need to follow a different release process.
 463
 464 Managed Release Integrated (MRI) Projects will provide the releases they want
 465 the Managed Snapshot Integrated (MSI) Projects to consume no later than two
 466 weeks after the start of the Managed Release. The TSC will decide by a majority
 467 vote whether to bump MSI versions to consume the new MRI releases. This should
 468 happen as early in the release as possible to get integration woes out of the
 469 way and allow projects to focus on developing against a stable base. If the TSC
 470 decide to consume the proposed MRI releases, all MSI Projects are required to
 471 bump to the new versions within a two day window. If some projects fail to
 472 merge version bump patches in time, the TSC will instruct Linux Foundation
 473 staff to temporarily wield committer rights and merge version bump patches.
 474 The TSC vote at any time to back out of a version bump if the new releases are
 475 found to be unsuitable.
 476
 477 MRI Projects are expected to provide bugfixes via minor or patch version
 478 updates during the release, but should strive to not expect MSI Projects to
 479 consume another major version update during the release.
 480
 481 MRI Projects are free to follow their own release cadence as they develop new
 482 features during the Managed Release. They need only have a stable version ready
 483 for the MSI Projects to consume by the next integration point.
 484
 485 Managed Release Integrated Checkpoints
 486 ++++++++++++++++++++++++++++++++++++++
 487
 488 The MRI Projects will follow similar checkpoints as the MSI Projects, but the
 489 timing will be different. At the time MRI Projects provide the releases they
 490 wish MSI Projects to consume for the next release, they will also provide their
 491 final checkpoints. Their midway checkpoints will be scraped one month before
 492 the deadline for them to deliver their artifacts to the MSI Projects. Their
 493 initial checkpoints will be due no later two weeks following the deadline for
 494 their delivery of artifacts to the MSI Projects. Their initial checkpoints will
 495 cover everything they expect to do in the next Managed Release, which may
 496 encompass any number of major version bumps for the MRI Projects.
 497
 498 Moving a Project from Unmanaged to Managed
 499 ------------------------------------------
 500
 501 Unmanaged Projects can request to become Managed by submitting a
 502 **Project_Plan** issue to the TSC project in Jira. See details as described
 503 under the `Initial Checkpoint`_ section above. Requests should be submitted
 504 before the start of a release. The requesting project should make it clear that
 505 they meet the Managed Release Project Requirements.
 506
 507 The TSC will evaluate requests to become Managed and inform projects of the
 508 result and the TSC's reasoning no later than the start of the release or one
 509 week after the request was submitted, whichever comes last.
 510
 511 For the first release, the TSC will bootstrap the Managed Release with projects
 512 that are critical to the OpenDaylight platform. Other projects will need to
 513 follow the normal application process defined above.
 514
 515 The following projects are deemed critical to the OpenDaylight platform:
 516
 517 * aaa
 518 * controller
 519 * infrautils
 520 * mdsal
 521 * netconf
 522 * odlparent
 523 * yangtools
 524
 525 Unmanaged Projects
 526 ==================
 527
 528 Requirements for Unmanaged Projects
 529 -----------------------------------
 530
 531 Unmanaged Project requirements are designed to be as low-overhead as possible
 532 while still allowing for participation in the final release. If Unmanaged
 533 Projects do not want to participate in the final release and instead provide
 534 their artifacts to their consumers through another channel, there are no
 535 requirements.
 536
 537 SNAPSHOT Versions by Release
 538 ++++++++++++++++++++++++++++
 539
 540 Unmanaged Projects can consume whichever version of their upstream dependencies
 541 they want during most of the release cycle, but if they want to be included in
 542 the final release distribution they must bump their versions to SNAPSHOT no
 543 later than one week before code freeze.
 544
 545 Jobs Required for Unmanaged Projects Running
 546 ++++++++++++++++++++++++++++++++++++++++++++
 547
 548 Unmanaged Projects that wish to take part in the final release must enable the
 549 validate-autorelease job. Unmanaged Projects can release artifacts at any time
 550 using the release job. To take part in the final release, Unmanaged Projects
 551 will need to run the release job with the version of the final distribution no
 552 later than one week before code freeze.
 553
 554 Added to Final Distribution POM
 555 +++++++++++++++++++++++++++++++
 556
 557 In order to be included in the final distribution, Unmanaged Projects must
 558 submit a patch to include themselves in the final distribution pom.xml file no
 559 later than one week before code freeze. Projects should only be added to the final
 560 distribution pom.xml after they have published artifacts with the release job
 561 to avoid breaking the build.
 562
 563 Unmanaged Release Process
 564 -------------------------
 565
 566 Unmanaged Projects are free to follow their own processes. To have their
 567 artifacts included in the final distribution, they need only follow the
 568 Requirements for Unmanaged Projects above by the deadlines. Note that Unmanaged
 569 Projects will not have any leeway for missing deadlines. If projects are not
 570 in the final distribution by one week before code freeze their artifacts will not be
 571 included in the final release, but they may still publish artifacts and help
 572 their consumers install them out-of-band.
 573
 574 Checkpoints
 575 +++++++++++
 576
 577 There are no checkpoints for Unmanaged Projects.
 578
 579 Moving a Project from Managed to Unmanaged
 580 ------------------------------------------
 581
 582 Managed Projects that are not required for dependency reasons can submit a
 583 **Project_Plan** issue to be Unmanaged to the TSC project in Jira. See details
 584 in the `Initial Checkpoint`_ section above. Requests should be submitted before
 585 the start of a release. Requests will be evaluated by the TSC.
 586
 587 The TSC may withdraw a project from the Managed Release at any time.
 588
 589 Installing Features from Unmanaged Projects
 590 -------------------------------------------
 591
 592 Unmanaged Projects will have their artifacts included in the final release if
 593 they are available on-time, but they will not be available to be installed
 594 until the user does a repo:add.
 595
 596 To install an Unmanaged Project feature, find the feature description in the
 597 system directory. For example, NetVirt's main feature:
 598
 599 system/org/opendaylight/netvirt/odl-netvirt-openstack/0.6.0-SNAPSHOT/
 600
 601 Then use the Karaf shell to repo:add the feature:
 602
 603 feature:repo-add mvn:org.opendaylight.netvirt/odl-netvirt-openstack/0.6.0
 604 -SNAPSHOT/xml/features
 605
 606 Grievances
 607 ==========
 608
 609 For requirements that are difficult to automatically ascertain if a Managed
 610 Project is following or not, there should be a clear reporting process.
 611
 612 Grievance reports should be filed against the TSC project in Jira. Very urgent
 613 grievances can additionally be brought to the TSC's attention via the TSC's
 614 mailing list.
 615
 616 Process for Reporting Unresponsive Projects
 617 -------------------------------------------
 618
 619 If a Managed Project does not meet the `Responsiveness`_ Requirements, a
 620 **Grievance** issue should be filed against the TSC project in Jira.
 621
 622 Unresponsive project reports should include (at least):
 623
 624 * Select the project being reported in the **ODL_Project** field
 625
 626 * Select the release version in the **ODL_Release** field
 627
 628 * In the **Summary** field, put something like:
 629   ``Grievance against Project-X``
 630
 631 * In the **Description** field, fill in the details:
 632
 633   .. code-block:: none
 634
 635      Document the details that show ExampleProject was slow to review a change.
 636      The report should include as much relevant information as possible,
 637      including a description of the situation, relevant Gerrit change IDs and
 638      relevant public email list threads.
 639
 640 * In the **ODL_Gerrit_Patch**, put in a URL to a Gerrit patch, if applicable
 641
 642 Release Schedule
 643 ================
 644
 645 The start date for odd release is September 7 and the start date for even
 646 release is March 7.
 647
 648 .. list-table::
 649    :widths: 20 20 20 40
 650    :header-rows: 1
 651    :stub-columns: 1
 652
 653    * - **Milestone**
 654      - **Time**
 655      - **Fluorine**
 656      - **Description**
 657
 658    * - Release Start
 659      - Start Date
 660      - 2018-03-07
 661      - Declare Intention: Submit **Project_Plan** Jira item in TSC project
 662
 663    * - Initial Checkpoint
 664      - Start Date + 2 weeks
 665      - 2018-03-22
 666      - Initial Checkpoint. All Managed Projects must have completed
 667        **Project_Plan** Jira items in TSC project.
 668
 669    * - Release Integrated Deadline
 670      - Initial Checkpoint + 2 weeks
 671      - 2018-04-07
 672      - Deadline for Release Integrated Projects (currently ODLPARENT and
 673        YANGTOOLS) to provide the desired version deliverables for downstream
 674        Snapshot Integrated Projects to consume.
 675
 676    * - Version Bump
 677      - Release Integrated Deadline + 1 day
 678      - 2018-04-08
 679      - Prepare version bump patches and merge them in (RelEng team). Spend the
 680        next 2 weeks to get green build for all MSI Projects and a healthy
 681        distribution.
 682
 683    * - Version Bump Checkpoint
 684      - Release Integrated Deadline + 2 weeks
 685      - 2018-04-21
 686      - Check status of MSI Projects to see if we have green builds and a
 687        healthy distribution. Revert the MRI deliverables if deemed necessary.
 688
 689    * - CSIT Checkpoint
 690      - Version Bump Checkpoint + 2 weeks
 691      - 2018-05-07
 692      - All Managed Release CSIT should be in good shape - get all MSI Projects'
 693        CSIT results as they were before the version bump. This is the final
 694        opportunity to revert the MRI deliverables if deemed necessary.
 695
 696    * - Middle Checkpoint
 697      - CSIT Checkpoint + 8 weeks
 698      - 2018-07-05
 699      - Checkpoint for status of Managed Projects - especially Snapshot
 700        Integrated Projects.
 701
 702    * - Code Freeze
 703      - Middle Checkpoint + 4 weeks
 704      - 2018-08-07
 705      - Code freeze for all Managed Projects - cut and lock release branch. Only
 706        allow blocker bugfixes in release branch.
 707
 708    * - Final Checkpoint
 709      - TSC meeting 2 weeks after Code Freeze
 710      - 2018-08-23
 711      - Final Checkpoint for all Managed Projects.
 712
 713    * - Formal Release
 714      - 6 months after Start Date
 715      - 2018-09-07
 716      - Formal release
 717
 718    * - Service Release 1
 719      - 1 month after Formal Release
 720      - 2018-10-07
 721      - Service Release 1 (SR1)
 722
 723    * - Service Release 2
 724      - 2 months after SR1
 725      - 2018-12-07
 726      - Service Release 2 (SR2)
 727
 728    * - Service Release 3
 729      - 2 months after SR2
 730      - 2019-02-07
 731      - Service Release 3 (SR3)
 732
 733    * - Service Release 4
 734      - 3 months after SR3
 735      - 2019-05-07
 736      - Service Release 4 (SR4) - final service release
 737
 738    * - Release End of Life
 739      - 4 months after SR4
 740      - 2019-09-07
 741      - End of Life - coincides with the Formal Release of the current release+2
 742        versions and the start of the current release+3 versions
 743
 744 Vocabulary Reference
 745 ====================
 746
 747 * Managed Release Process: The release process described in this document.
 748 * Managed Project: A project taking part in the Managed Release Process.
 749 * Unmanaged Project: A project not taking part in the Managed Release Process.
 750 * Simultaneous Release: Event wherein all Snapshot Integrated Project versions
 751   are rewriten to release versions and release artifacts are produced.
 752 * Snapshot Integrated Project: Project that integrates with OpenDaylight
 753   projects using snapshot version numbers. These projects release together in
 754   the Simultaneous Release.
 755 * Release Integrated Project: Project that releases independently of the
 756   Simultaneous Release. These projects are consumed by Snapshot Integrated
 757   Projects based on release version numbers, not snapshot versions.
 758
 759 .. _Committer Removal Process: https://wiki.opendaylight.org/view/TSC:Main#Committer_Removal_Process