<div dir="ltr"><div>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. <br></div><div><br></div>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).<div><br></div><div>I'd like to know the best way of dealing with this, options are:</div><div>a) make the python import optional, change the unit test to not require the newer tripleo-common</div><div>b) allow the unit test job to pull in pre-release versions like 7.0.0.0b1</div><div>c) change tripleo-common release-model to cycle-with-intermediary and immediately release a 7.0.0</div><div><br></div><div>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.</div><div><br></div><div><div>[1] <a href="https://review.openstack.org/#/c/448300/">https://review.openstack.org/#/c/448300/</a></div></div></div>