[puppet] Artificially inflated dependencies in metadata.json of all modules

Alex Schultz aschultz at redhat.com
Thu Mar 25 20:56:56 UTC 2021

On Thu, Mar 25, 2021 at 2:48 PM Thomas Goirand <zigo at debian.org> wrote:

> On 3/25/21 9:22 PM, Thomas Goirand wrote:
> > Hi Alex,
> >
> > Thanks for your time replying to my original post.
> >
> > On 3/25/21 5:39 PM, Alex Schultz wrote:
> >> 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.
> >
> > Not at all. I'm asking for dependency to vaguely reflect reality, like
> > we've been doing this for years in the Python world of OpenStack.
> >
> >> This existing release model has been in place for at least 5
> >> years now if not longer
> >
> > Well... hum... how can I put it nicely... :) Well, it's been wrong for 5
> > years then! :)
> Let me give an example. Today, puppet-ironic got released in version
> 18.3.0. The only thing that changed in it since 18.2.0 is a bunch of
> metadata bumping to 18.2.0...
> Why haven't we just kept version 18.2.0? It's the exact same content...
Release due to milestone 3.  Like I said, we could switch to independent or
just stop doing milestone releases, but then that causes other problems and
overhead.  Given the lower amount of changes in the more recent releases,
it might make sense to switch but I think that's a conversation that isn't
necessarily puppet specific but could be expanded to openstack releases in
general.  From a RDO standpoint, we build the packages in dlrn which
include dates/hashes and so the versions only matter for upgrades (we don't
enforce the metadata.json requirements).  Dropping milestones wouldn't
affect us too badly, but we'd still want an initial metadata.json rev at
the start of a cycle.  We could hold off on releasing until much later and
you wouldn't get the churn. You'd also not be able to match the puppet
modules to any milestone release during the current development cycle.

> Cheers,
> Thomas Goirand (zigo)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210325/9fa5515e/attachment-0001.html>

More information about the openstack-discuss mailing list