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
Guidance: What kinds of things are published to maven and/or Docker Hub?
Look at these steps after our next release (end of March)
