nice, thanks

k8s people, pls have a look, https://github.com/voxpupuli/puppet-k8s/pull/58

This module seems not having any love. concat 9 is the latest

puppet-autofs' (v7.1.0) requires 'puppetlabs-concat' (>= 4.1.0 < 8.0.0)

See the

puppet-autofs

module at https://forge.puppet.com/puppet/autofs?src=slack&channel=voxpupuli

I take it back, commits are there, just no release yet

@vchepkov https://github.com/voxpupuli/puppet-autofs/pull/197

I can do a release afterwards

@vchepkov https://github.com/voxpupuli/puppet-autofs/pull/201

morning o/

can I get a review for https://github.com/voxpupuli/voxpupuli-acceptance/pull/61

This message was deleted.

I still think it would be nice to have a way to identify those legacy functions in other modules

that's not easily possible anymore with that change

IMO, that actually did more harm than good recently. It forced you into updating everything everywhere to now depend on stdlib 9 making it very difficult to upgrade one thing without having to upgrade your whole world. If the errors hadn't have been thrown, then there would have been no rush and we could have gradually made changes as the adoption of stdlib 9 became more widespread.

yes. but as a maintainer I would like to at least identify legacy stuff that I need to purge in the future

I think puppet-lint is probably more suitable then. You can acknowledge that the function needs to be updated at some point (but you're not doing it just yet), with a control comment.

can I just do two major releases in a row?

first to drop Puppet 6 + EoL OS and a second one to drop stdlib < 9

I suppose. I'd be waiting on all the stdlib 9 bugs and blockers to be found and resolved as the benchmark on when it's right to require that version. We might actually be quite close. Dunno. The

ensure_packages

issue in stdlib 8 took about a year before it was fixed, and that stopped quite a few people from upgrading.

my point is that's it's easy to switch to stdlib 9 while doing a major release for dropping EoL OS + puppet 6. if we split that now that requires an additional major review on our side and time

and since many of our modules depend on each other it cascades

Does bumping a dependency actually require a major version bump?

which dependency do you mean

it's hard to say, but raising the minimum version of stdlib to 9 can be very painful

I suspect there are plenty of occasions where we've bumped the stdlib version in metadata (for instance to get access to a new type alias), and that's not been considered worthy of a new major version of the client module.

agreed, a new minor version is something I also do

ewoud: agreed. Unfortunately that's happened in countless places. It was an oversight to have not realised that strict=error would mean a hard fail, and unfortunate that it's taken so long to remedy via https://github.com/puppetlabs/puppetlabs-stdlib/pull/1377 and a new 9.0.1 release.

We'd used the pattern a handful of times before (extlib, puppetlabs/postgresql etc), and I don't recall anyone having brought it up. I suspect this means nobody changes the default setting for

strict

...