action #16374
Updated by okurz over 7 years ago
## user story As a conservative user I want stable versions of openQA so that I am not scared away of using openQA by occasional critical issues in the "devel:openQA" version ## acceptance criteria * **AC1**: A documented workflow exists, e.g. wiki, e.g. based on "suggested workflow" below * **AC2**: Maintainer have been found * **AC3**: An OBS project exists with stable versions with openQA documentation references ## tasks * ask openQA team if we really need this * talk to aaannz and coolo how it has been done previously with 'devel:openQA:stable' and adopt * optional: helper scripts for the workflow * optional: Also adopt the workflow for submissions to openSUSE:Factory and maybe Leap and SLE, too ## further details ### Suggested workflow okurz suggests the following for anyone who is up to the task to do: * on a bi-weekly basis looks for the last git commit of openQA that is not totally broken * `git log --format=oneline <last_tag>..<the_one_commit_that_should_become_the_new_version> > changelog` * filter out un-interesting stuff from the changelog, e.g. low-level internal refactoring and fixes for issues that never hit users * create tag with message details including the changelog and with an increasing version number, e.g. 4.5, 4.6, …, 4.99, …, 4.165 * put that as "release" on the github project * make OBS package `devel:openQA:stable/openQA` automatically be triggered by new releases on github with the according version and changelog * do the same for os-autoinst * every 6w (that would be for each "milestone", covering three releases) collect changelog from all 6 releases (3 openQA + 3 os-autoinst) the interesting parts on an even higher level, blog about it and brag about it ### interesting references * http://keepachangelog.com/ * https://github.com/skywinder/Github-Changelog-Generator