Re: [openstack-dev] [tripleo][release] release-model of tripleo-common

[Ben Nemec]

On 04/18/2017 10:29 PM, Steve Baker wrote:



On Wed, Apr 19, 2017 at 1:14 PM, Doug Hellmann > 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/


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

Re: [openstack-dev] [tripleo][release] release-model of tripleo-common

[Steve Baker]

On Wed, Apr 19, 2017 at 1:14 PM, Doug Hellmann 
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/
>
> 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/
__
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

Re: [openstack-dev] [tripleo][release] release-model of tripleo-common

[Doug Hellmann]

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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tripleo][release] release-model of tripleo-common

[Steve Baker]

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/
__
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