Open Stack

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! :)

And if I'm being vocal now, it's because it's been annoying me for that
long.

> so reworking the tooling/process to understand your requirement

That's not for *my* requirement, but for dependencies to really mean
what they should: express incompatibility with earlier versions when
this happens.

> seems a bit much given the lack of contributors.

The above sentence is IMO the only valid one of your argumentation: I
can understand "not enough time", no problem! :)

> 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.

I could get away with no version relationship at all, but that's really
not the right thing to do. I'd like the dependencies to vaguely express
some kind of reality, which isn't possible the current way. There's no
way to get away from that problem with tooling: the tooling will not
understand that an API has changed in a module or a puppet provider.
It's only the authors of the patches that will know.

Perhaps we should also try to have some kind of CI testing to validate
lower bounds to solve that problem? </troll>

Cheers,

Thomas Goirand (zigo)