PendingComplete


Event / TimelineCommentsWhoapplies to SRs
Communicate code freeze to projects2 weeks before code freeze happensrelease manageryes
Code freeze (stable branch lock)3 weeks before any release.LF ITyes
Pick RC and produce CSIT spreadsheetAll blocker bugs must be closed before picking the RC. This is tentative date.integration/testyes
Vet CSIT failuresMax 1 week after CSIT spreadsheet is shared.all projectsyes
TSC votes the Managed release
TSCyes
Unlock stable branch
LF ITyes
Remind PTL to produce release notes (only for GA release)
release managerno
Publish released artifacts to Nexus
LF ITyes
Communicate Managed release to Self Managed projects
release manageryes
Release All SM projects (including "official" distribution)Max 1 week after Managed release.All SM projects (including int/dist)yes
Update docsdocs teamsome

Branch docs project

  • on master branch bump versions to next release (conf.yaml)
    • Clear per-project release notes in master to prep for next release
  • on new stable/branch update links to stable/branch away from "latest" (conf.py)
docs teamno
  • No labels

6 Comments

  1. Jamo Luhrsen

    • we need to track the release integrated deadline. that's the deadline for when all those MRI projects like odlparent, yangtools, etc have to have their final versions done and available for the rest of the snapshot projects. It's essentially the same as Version Bump though. Maybe just combine that row and indicate that it's our deadline for MRI to be released and version bumping the projects.
    • you don't have Version Bump Checkpoint or CSIT Checkpoint that happens between the Middle Checkpoint. That is important for someone to track and bug everyone to make sure that the Version bump did not horribly break projects. There may be some hiccups in the Version Bump Checkpoint, but they need to be ironed out or acceptable by the CSIT checkpoint otherwise the projects have the right to reject the version bump and roll back to the previous versions.
    • You don't have code freeze here.

  2. Luis Gomez

    I think this should be all actions we have to complete to create an ODL release (GA or SR), this should not be milestone check like it seems in this table (e.g. initial, middle checkpoints).

    1. Daniel De La Rosa

      Actually i was thinking of that too.. This shouldn't be a copy of the milestones but the actions for an ODL just to refer to what we do after the final checkpoint? 

      1. Jamo Luhrsen

        fair enough. I wasn't thinking along those lines when I open the page and saw some, but not all, of our full release checkpoints.

        So, if that's all we want, then maybe you make the assumption that the reader of this page will already have the RC build,
        and the TSC's vote that it can be released. Then, what's next? Off the top of my head:

        • get release notes
        • get self-managed projects to jump through their hoops (within a week)
        • produce the final distribution
        • update the downloads page with the final distribution
        • unlock the branch
        • ???


  3. Daniel De La Rosa

    Abhijit Kumbhare Let's the review this page in our next TSC meeting. I think we need to move it to release information though 

    1. Abhijit Kumbhare

      Sure.