<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 25, 2021 at 10:30 AM Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Each time there's a new release, all of the modules are getting a new<br>
set of lower bounds for:<br>
- openstack/keystone<br>
- openstack/openstacklib<br>
- openstack/oslo<br>
<br>
I just did a quick check and this really doesn't make sense. For<br>
example, for going from 18.2.0 to 18.3.0, there's no breakage of the API<br>
that would require a bump of version in all modules.<br>
<br></blockquote><div><br></div><div>These are milestone releases and not tracked independently across all the modules. I believe you are basically asking for the modules to go independent and not have milestone releases.  While technically the version interactions you are describing may be true for the most part in that it isn't necessary, we assume the deployment as a whole in case something lands that actually warrants this.  The reality is this only affects master and you likely want to not track the latest versions until GA.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So, could we please stop this non-sense and restore some kind of sanity<br>
in our dependency management ? FYI, I'm expressing these in the packaged<br>
version of the puppet modules, and it increase complexity for no reasons.<br>
<br></blockquote><div><br></div><div>It feels like the ask is for more manual version management on the Puppet OpenStack team (because we have to manually manage metadata.json before releasing), rather than just automating version updates for your packaging.  This existing release model has been in place for at least 5 years now if not longer so reworking the tooling/process to understand your requirement seems a bit much given the lack of contributors.  If you feel that you could get away with requiring >= 18 rather than a minor version, perhaps you could add that logic in your packaging tooling instead of asking us to stop releasing versions.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
A lower bound of a dependency should be increased *only* when really<br>
mandatory (ie: a backward compatibility breakage, a change in the API,<br>
etc.).<br>
<br>
Your thoughts?<br>
<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<br>
</blockquote></div></div>