3:45 p.m.
Hello Everybody,
Had some great conversations and feedback this week about the release process for Hawkular
Metrics. A few ideas emerged and this email is a summary of the process Hawkular Metrics
will implement starting next release (expected as soon as next week).
Release Process:
1) Use semver as the versioning standard (http://semver.org/)
2) A scheduled release:
a) is a planned release, with a set of significant changes
b) is the next increment on MAJOR.MINOR version (eg: from 0.4.0 to 0.5.0)
c) gets a dedicated branch from master
d) gets tagged on the branch
e) gets full release notes, JIRA, email communication, blog
f) bits are published to JBoss Nexus and Github
3) A patch release
a) needed to address urgent bugs or regression between scheduled releases
b) is an increment in the PATCH version (eg. 0.4.2)
c) no dedicated branch, patches are applied to the branch of a 'scheduled
release'
d) gets tagged on the working branch
e) no release notes, blog posts, or similar communication; the only official
communication will be a list of JIRAs fixed
f) bits published to JBoss Nexus and Github
g) all the code fixes will be applied retroactively to master
Hawkular Metrics will keep 'scheduled releases' at roughly one a month. The
'patch releases' will be created on a need basis and only if there are JIRAs
reported against the 'scheduled release' or 'patch release' that need to
be addressed before the next 'scheduled release'. One goal with the patch releases
is to avoid publish a huge number of them in a short amount of time (eg. 2 per day). This
does not impact at all the release for SNAPSHOTS; they will continue to get published from
the code in the master branch.
It would be great if all the projects converge on a similar process. I recognize that due
to different maturity levels that might not be practical now for everybody, but it would
be huge win for the entire Hawkular to make even small steps in the same direction.
Thank you,
Stefan Negrea
Software Engineer