Open Stack

On 04/18/2017 10:29 PM, Steve Baker wrote:
>
>
> On Wed, Apr 19, 2017 at 1:14 PM, Doug Hellmann <doug at doughellmann.com
> <mailto:doug at 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.