Open Stack

On 2019-03-05 14:23:50 -0700 (-0700), Boden Russell wrote:
[...]
> > On Tue, 2019-03-05 at 18:52 +0000, Jeremy Stanley wrote:
> >> The primary risk with developing only against unreleased source of
> >> your dependencies, when your users expect to deploy your releases
> >> with released dependencies, is that you can end up accidentally
> >> releasing something which only works with unreleased and potentially
> >> unsupported states of its dependencies.
> 
> If I understand correctly, that risk only applies to consumers of
> "beta releases" during the dev cycle (other openstack projects for
> testing I'd guess). What gets packaged/installed in terms of a
> release deliverable would still be tested with dependencies pinned
> via stable branch contents, not them from git source.
> 
> Is this correct?

If (arbitrary example) you only ever test neutron against the master
branch state of neutron-lib and not against the released state of
neutron-lib, then when it comes time to tag neutron for a new
release there's a chance you've grown to expect some unreleased
behavior change in neutron-lib which was introduced since its most
recent release. Then when users attempt to deploy and run neutron it
breaks because their installation of the most recent version of
neutron-lib is still too old to support their installation of the
most recent version of neutron.

> I think we may have a special case here in neutron land as part of our
> neutron-lib effort [1][2]. We are aggressively rehoming [2] common code
> from neutron into neutron-lib and then consuming it in neutron and other
> networking projects (currently 20 projects in total). Due to the volume
> of code changes involved and the potential for cross-project
> dependencies, testing only with tagged releases implies an extra step in
> this process that could hinder velocity.
> 
> Am I wrong to think that maybe this special case could warrant testing
> from git master source rather than tagged releases during the dev cycle?
> 
> Or perhaps we just start doing a lot more releases of these networking
> projects during the dev cycle?
> 
> 
> [1] https://blueprints.launchpad.net/neutron/+spec/neutron-lib-decouple-db
> [2]
> https://docs.openstack.org/neutron-lib/latest/contributor/contributing.html

If you freeze neutron-lib after its last release of the cycle and
don't accept any new changes to it until after everything which
tests against its branch tip also releases, then you might be
protected from this class of problem.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190305/9a938936/attachment.sig>