On 04/18/2017 10:29 PM, Steve Baker wrote:
On Wed, Apr 19, 2017 at 1:14 PM, Doug Hellmann <d...@doughellmann.com <mailto:d...@doughellmann.com>> wrote: 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/ <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). OK, thanks. We need to determine now whether to release 7.0.0.0b1 as 7.0.0, or release current master: http://git.openstack.org/cgit/openstack/tripleo-common/log/
Hmm, I'm probably going to run into the same problem with https://review.openstack.org/#/c/431145/ because we start using instack-undercloud as a library instead of a standalone project. While we're making this change for tripleo-common anyway I'd like to do it for instack-undercloud as well.
It's probably safest to release b1 as 7.0.0 since we know all of those b1 releases worked together, but our integration jobs do actually test all of the latest branches together so we're probably okay to just release master if we want. There's the possibility of breaking unit tests though, I guess.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
