Release requests and history tracking
Go to file
Tony Breeds 828e285701 Add a 'generic' release-type.
We use release-types as a way to verify that versions are compatible and
if needed reflected accurately in the code (puppet, xstatic).  If one
isn't set explicitly then we assume python-service.

In certain circumstances (anything other than the first release in a
series) we also perform python specific requirements checking on all
'python' types.

Add a new 'generic' type that uses the same rules to validate version
numbers but wont run any python specific checks.

We need this a projects (like monasca-thresh) will fail the requirements
check for 2nd or greater releases[1].

An alternate would be to have the requirements code check if setup.py
exists before calling it but that seems like the wrong layer to me.

[1] http://logs.openstack.org/54/652854/1/check/openstack-tox-validate/80df01c/job-output.txt.gz#_2019-04-16_06_08_00_636538
Change-Id: I3fcde5eb266f954fddb6871ce8690b93b8fd7a8d
2019-04-18 15:27:27 +10:00
deliverables Merge "[keystone] final releases for pike" 2019-04-17 23:32:29 +00:00
doc Mark Stein as released 2019-04-10 11:30:01 +00:00
openstack_releases Add a 'generic' release-type. 2019-04-18 15:27:27 +10:00
templates switch mailing lists to openstack-discuss 2018-12-04 10:41:28 -05:00
tools Add script to transition entire series to EM or EOL 2019-04-11 06:44:55 -05:00
.gitignore Switch to stestr 2018-07-10 10:38:33 +07:00
.gitreview Added .gitreview 2015-07-02 09:25:52 +00:00
.stestr.conf Switch to stestr 2018-07-10 10:38:33 +07:00
.zuul.yaml Revert "Increase tag-releases job timeout" 2019-04-16 14:13:40 +00:00
bindep.txt install the python3 version of launchpadlib 2018-06-21 16:28:06 -04:00
CONTRIBUTING.rst Base ladder content for CONTRIBUTING.rst 2018-03-22 16:10:28 +01:00
LICENSE Add top level LICENSE file 2018-10-17 10:36:04 +11:00
README.rst Point to release-management info in governance 2018-11-01 16:09:48 +01:00
requirements.txt Use recommended twine check for README validation 2019-04-05 10:56:16 -05:00
setup.cfg switch mailing lists to openstack-discuss 2018-12-04 10:41:28 -05:00
setup.py [Trivial] Remove executable privilege of setup.py 2016-05-09 16:38:37 +00:00
test-requirements.txt Switch to stestr 2018-07-10 10:38:33 +07:00
tox.ini Add a 'generic' release-type. 2019-04-18 15:27:27 +10:00
watched_queries.yml remove extra blank line in watched query output 2017-08-04 10:26:22 -04:00
yamllint.yml add linter rules for vertical whitespace 2017-07-31 17:26:33 -04:00

Using This Repository

All official OpenStack software should go through the Release Management team team to produce releases. Exceptions to this rule are granted by the Technical Committee and documented in the openstack/governance repository ('release-management' key in reference/projects.yaml).

This repository is used to track release requests. Releases are managed using groups of "deliverables", made up of individual project repositories sharing a Launchpad group and a version number history. Many deliverables will only have one constituent project repository.

The repository is managed by the Release Management team.

image

Refer to the reference documentation for more details

Deliverables managed by teams not under OpenStack governance should follow the tagging instructions in the infra manual.