Skip to end of metadata
Go to start of metadata



Optional dial in:
Dial in: 401-283-5773
PIN: 66343

  • note the changed dial in number and pin



  • Releasing components - scheduling and process guidance

Discussion items

  • Review Action Items
  • Agenda review

Releasing componentsJosh taking notes

Discuss how components are released, and how to fit them into a reference distribution release schedule

  • dependencies
  • feature maturity
  • beta/


For reference, go over the current rolling a release.

Example release timing:

  • All tests pass
    • Features should be checked that they worked - manual regression testing
  • Bugs addressed
  • Release notes for component (features working, need some standard - technical, list of tickets, more like a change log)
    • JIRA may be able to generate release notes, but sometimes not everything matches - not too accurate.  One way to look at it is to look at all the commits.  Might be a problem if components aren't their own project - the fix version field is for the ref distro.
    • Component lead directs developers to update the release notes as they work on a ticket
  • Demo data - it should be appropriate for a release
  • Bump the version (serviceVersion) -
    1. change the version in or
    2. Jenkins looks at that version in or and uses that when publishing
    3. manually check that version is released to docker hub and/or maven central
    4. separate commit to bump to the version that comes after the just released version (as SNAPSHOT)
  • Updating deployments
    • contract tests updated to next SNAPSHOT version (consumer of docker hub)
    • deployments updated to either released (UAT, demo) version, or SNAPSHOT (test) (consumer of docker hub)
  • Announce it
    • emails, notify the larger group, etc
    • telling any dependents so they can start building against the new stuff
  • We don't have a programmatic way to check dependencies version.
    • Be really clear in release notes? E.g. the ref UI has lots of components, each should document what Service it works for.
    • Dependents should break in a nice way - log it, show a nice error to the user (UI), etc.  Be polite to each other
    • We could build this (Services do report publicly what their version is) - when will we need it?  We haven't had a problem yet, so perhaps wait until we do to get clear requirements before building.
      • Perhaps a build time check
      • Do we need it?  ROI seems a bit low and so that's why we haven't done it yet

Action items

  • Guidance: What kinds of things are published to maven and/or Docker Hub?
  • Look at these steps after our next release (end of March)