<div dir="ltr"><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 25, 2021 at 2:26 PM 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 Alex,<br>
<br>
Thanks for your time replying to my original post.<br>
<br>
On 3/25/21 5:39 PM, Alex Schultz wrote:<br>
> It feels like the ask is for more manual version management on the<br>
> Puppet OpenStack team (because we have to manually manage metadata.json<br>
> before releasing), rather than just automating version updates for your<br>
> packaging.<br>
<br>
Not at all. I'm asking for dependency to vaguely reflect reality, like<br>
we've been doing this for years in the Python world of OpenStack.<br>
<br>
> This existing release model has been in place for at least 5<br>
> years now if not longer<br>
<br>
Well... hum... how can I put it nicely... :) Well, it's been wrong for 5<br>
years then! :)<br>
<br>
And if I'm being vocal now, it's because it's been annoying me for that<br>
long.<br>
<br></blockquote><div><br></div><div>Versions in puppet have always been problematic because of the incompatibilities between how python can handle milestones vs puppet in the openstack ecosystem. Puppet being purely semver means we can't do any of the pre-release (there is no 13.3.0.0a1) things that the other openstack projects can do.  So in order to do this, we're releasing minor versions as points during the main development to allow for folks to match up to the upstream milestones.  Is it ideal? no.  Does it really matter? no.  Puppet modules inherently aren't package friendly. metadata.json is for the forge where the module dependencies will automagically be sorted out and you want the modules with the correct 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">
> so reworking the tooling/process to understand your requirement<br>
<br>
That's not for *my* requirement, but for dependencies to really mean<br>
what they should: express incompatibility with earlier versions when<br>
this happens.<br>
<br></blockquote><div><br></div><div>It is your requirement because you're putting these constraints in place in your packaging while tracking the current development.  As I mentioned this is only really an issue until GA. Once GA hits, we don't unnecessarily rev these versions which means there isn't the churn you don't particularly care for. </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">
> seems a bit much given the lack of contributors.<br>
<br>
The above sentence is IMO the only valid one of your argumentation: I<br>
can understand "not enough time", no problem! :)<br></blockquote><div><br></div><div>Given the number of modules, trying to maintain the versions with the super strict semver reasons causes more issues than following a looser strategy to handle versions knowing that there are likely going to be breaking changes between major releases. In puppet we try to maintain N and N-1 backwards compatibilities but given the number of modules it makes it really really hard to track and the overall benefit to do so is minimal.  If we follow the patterns usually a major version bump hits on m1 and X.3 is the GA or RC version.  </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">
<br>
> If you feel that you could get away with requiring >= 18 rather than a<br>
> minor version, perhaps you could add that logic in your packaging<br>
> tooling instead of asking us to stop releasing versions.<br>
<br>
I could get away with no version relationship at all, but that's really<br>
not the right thing to do. I'd like the dependencies to vaguely express<br>
some kind of reality, which isn't possible the current way. There's no<br>
way to get away from that problem with tooling: the tooling will not<br>
understand that an API has changed in a module or a puppet provider.<br>
It's only the authors of the patches that will know.<br>
<br></blockquote><div><br></div><div>There is, don't add a strict requirement beyond the major version or wait until GA before implementing minimum versions.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Perhaps we should also try to have some kind of CI testing to validate<br>
lower bounds to solve that problem? </troll> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<br>
</blockquote></div></div>