...
- if there is any new feature/enhancement:
- the patch version should be bumped
- if a change is a bugfix bug fix on a previously merged patch, AND if that previous version is not already released:
- then changing the version is optional
...
- The repos need to have the version number expressed in multiple places
- In pom.xml, the project/version value is always specified as either W.X.Y or W.X.Y-SNAPSHOT, as in 1.3.2-SNAPSHOT.
- Every directory that has a pom.xml file should ALSO have a version.properties file AND a ChangeLog.md file.
- The exception is when there are subdirectories with individual pom.xml files. In that case, those directories should have a ChangeLog.md file. Typically these match the docker containers.
- The same value (without any "-SNAPSHOT" suffix) will be specified in version.properties, separated out into separate major, minor and patch values:
- major=W
- minor=X
- patch=Y
- The same value will be specified in the ChangeLog.md file.
- These values MUST match.
- When an artifact (e.g docker container) is "released", a corresponding file will be added to the releases directory. The version of that release file must also match the version found in the pom.xml, version.properties and ChangeLog.md files.
Check the Build Console Output
...
- Ensure no outstanding patch remaining in gerrit for review/merge for container being released. We would want to avoid releasing container too frequently as well (consider consolidating release for multiple patch)
- As artifiact release impacts different repositories (blueprint/bootstrap, oom etc); consolidate release request (and subsequent update to other impacted repositories)
- For self-release yaml, ensure comment include description of changes/bug fixes introduced in that version. If multiple jira's are consolidated - include all Jira reference/brief summary
ChangeLog.md file
...
In the Istanbul release, we have adopted the practices of keeping a changelog. Best practices for changelogs can be found at <keepachangelog.com>.
...
- The name of the changelog may be specified in any case, but at least the letter "C" must be capitalized. We are using markdown, so the extension must always be "
.md". - Within the changelog:
- The date stamp must always be specified as either YYYY-MM-DD or YYYY/MM/DD.
- The JIRA ticket associated with the changes that went into a version should be noted.
- It is not necessary to have both the JIRA ticket number AND a link to the JIRA ticket.
- There should be an entry for every single version.
- The latest version must always be first, in reverse time order.
- The date stamp should always reflect the most recent change associated with a given version.
- An [Unreleased] section is optional. (JIRA tickets should be used in lieu of an [Unreleased] section.)
...