Other than being consumed as a library, tripleo-common is the home for a number of tripleo related files, image building templates, heat plugins, mistral workbooks.
I have a python-tripleoclient[1] change which is failing unit tests because it depends on changes in tripleo-common which have landed in the current cycle. Because tripleo-common is release-model cycle-trailing, tripleo-common 7.0.0.0b1 exists but the unit test job pulls in the last full release (6.0.0). I'd like to know the best way of dealing with this, options are: a) make the python import optional, change the unit test to not require the newer tripleo-common b) allow the unit test job to pull in pre-release versions like 7.0.0.0b1 c) change tripleo-common release-model to cycle-with-intermediary and immediately release a 7.0.0 I think going with c) would mean doing a major release at the start of each development cycle instead of at the end, then doing releases throughout the cycle following our standard semver. [1] https://review.openstack.org/#/c/448300/
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
