Excerpts from Steve Baker's message of 2017-04-19 13:05:37 +1200: > 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/
As a library, tripleo-common should not use pre-release versioning like alphas and betas because of exactly the problem you've discovered: pip does not allow them to be installed by default, and so we don't put them in our constraint list. So, you can keep tripleo-common as cycle-trailing, but since it's a library use regular versions following semantic versioning rules to ensure the new releases go out and can be installed. You probably do want to start with a 7.0.0 release now, and from there on use SemVer to increment (rather than automatically releasing a new major version at the start of each cycle). Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
