Open Stack

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