Open Stack

On Tue, 2019-03-05 at 22:21 +0000, Jeremy Stanley wrote:
> 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.
well you could get around that by having the lower-constaints job use
the pypi releases. by convention we run the full unittest suite in lower constrains
so it might not be as much coverage as you might like but it should catch alot
of incompatibilities. i personly woudl still want at least on voting tempest job
that used the latest package and perferally the oldest package however we don't have the
latter today.
> 
> > 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.