On 3/5/19 12:15 PM, Sean Mooney wrote:> so personally i would expect the majority of neutrons gate jobs to used the released versions
but we proablly coudl have a neutron-next jobs that was bassically the full tempst job that specifically used master
I wasn't talking about neutron's jobs, but rather other networking projects that use neutron + other networking projects... But I suspect the same applies to them as well.
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? 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