Skip to end of metadata
Go to start of metadata


Date

7AM PST

https://www.uberconference.com/villagereach-isg

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

  • note the changed dial in number and pin

Attendees

Goals

  • Releasing components - scheduling and process guidance

Discussion items

TimeItemWhoNotes
5mStartJosh
  • 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/

Notes


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 version.properties or gradle.properties
    2. Jenkins looks at that version in gradle.properties or version.properties 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)