2017-03-21 Meeting note
Date
Mar 21, 2017
7AM PST
Meeting Link
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
@Josh Zamor (Deactivated)
@Elias Muluneh
@Jeff Xiong (Unlicensed)
@Pengfei Cui (Deactivated)
@Sebastian Brudziński
@Paweł Gesek
@Nikodem Graczewski (Unlicensed)
@Nick Reid (Deactivated)
@Chongsun Ahn (Unlicensed)
@Ben Leibert
@Brandon Bowersox-Johnson
@Mary Jo Kochendorfer (Deactivated)
Goals
Releasing components - scheduling and process guidance
Discussion items
Time | Item | Who | Notes |
|---|---|---|---|
5m | Start | Josh |
|
| Releasing components | Josh taking notes | Discuss how components are released, and how to fit them into a reference distribution release schedule
|
Notes
For reference, go over the current rolling a release.
Example release timing:
Gliffy Diagram is only supported by the cloud editor
Because Forge macros arent supported by the legacy editor, you'll need to convert this content to the cloud editor to display this macro properly. Find out more about converting to the cloud editor
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) -
change the version in version.properties or gradle.properties
Jenkins looks at that version in gradle.properties or version.properties and uses that when publishing
manually check that version is released to docker hub and/or maven central
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