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)