Release Process

From wiki.gpii
Jump to: navigation, search

Note: This page may be partially out of date.

Introducing Releases

Starting in the end of 2012, the Core architecture team will be introducing periodical releases of the core architecture framework, with the first release coming out mid-December. There are several reasons we are starting to do these releases:

  • Stabilizing codebase for SP3 Implementers, Matchmaker teams, etc., to work with
  • Give a better overview of what’s implemented
  • Easier planning for everyone, by knowing what to expect when
  • An occasion for the architecture team to stop and:
    • Test/confirm the code works
    • Write/update documentation
    • Get an overview of where we are, open JIRAs, etc.
    • Get input from other WPs
    • Announce changes in the codebase

Release Process

  • Collect input for required/desired features (release -3 months)
    • Set up a wiki page for release
    • Set preliminary date
    • Go through bugtracker to find and assign blockers
    • Write to SP3, architecture, MM and C4A lists and request needed/desired features.
  • Decide release scope, fix dates (release -2 months)
    • Based on input and open JIRAs, decide what will make it into the release
    • Fix release date
  • Feature Freeze (release -3 weeks)
    • Cut scope: based on time left, and pending features
    • Only features in new scope are allowed to be worked on
  • Code Freeze (release -1.5 weeks)
    • Repository is frozen except for fixes for blocking JIRAs / open pull requests
    • COLIN: Branch main repository to release (eg. v0.1)?????????
  • Testing (release -1 week)
    • QA Testing of the release (see QA Testing)
    • If any code is merged this week, affected areas need to be retested
  • Create downloadable packages (mid-late testing)
    • Should be done when we are relatively certain that the code works (ie. late testing)
    • Test installation
  • Release! (release date)
    • Write release notes on wiki page (release date)
    • ​Cut tag on GitHub
    • Announce release to architecture list (release date)
    • Release in JIRA, reassign bugs to later releases
    • JIRA gardening
  • Feature walk through (post release)
  • Architecture team does a call, presenting new features in more details, answering questions, etc.
    • call will be recorded

Release numbering

While the rules for incrementing version numbers will need to be integrated with the process above, for now here is the Semantic Versioning numbering scheme that is used for the core architecture and other components (e.gK the listeners).