https://www.puppet.com/community logo
Join Slack
Powered by
# voxpupuli
  • a
  • a
    I think I’m fine with spamming warnings TBH.
  • v
    bastelfreak, =2.7
  • v
    bastelfreak, today we only deploy on 2.7. if the code is 3.0+ compatible that's great, but core isn't yet ;)
  • v
    nice
  • b
    @Alex Fisher I'm still unsure. My initial thought was to not add the shims at all and drop all the legacy functions
  • a
    Lol. That’s creates an awful lot of pain.
  • b
    more pain than we've now?
  • a
    The pain now is mostly reserved for those already with strict mode turned on. Removing the shims would create pain for everyone
  • b
    then they will have the pain when stdlib 10 comes out
  • b
    under the assumptions that we don't forget to remove the deprecated functions
  • a
    But you get the chance to upgrade your modules over a period of time. Right now you might have to upgrade everything in a single commit to your Puppetfile. This isn’t an option for a lot of folks.
  • b
    yeah I know. maybe the approach with just calling warn() and notify{} works better
  • a
    Adding resources to the catalog is much more intrusive though.
  • b
    who reads puppetserver.log? 🙂
    💯 2
  • a
    (And a harder change to implement)
  • b
    how do you convince people to upgrade when you're not intrusive
  • a
    But it gives time for all the module authors to get releases out (and follow up bug fix releases etc)
  • a
    When the time comes to switch the deprecations to errors, there’s hopefully a lot fewer things you have to fix.
  • a
    I want to remove the blockers to upgrading. Right now, to get latest versions of eg. our modules you now require stdlib 9. But maybe you can’t upgrade to that because of X other modules you have.
  • b
    I think the root cause is that the new functions aren't available in stdlib 8
  • b
    that would have enabled maintainers and users to switch to them while being compatible with stdlib 8 and 9
  • a
    But that’s what 9 should be. A forgiving version with both.
  • b
    from a users point of view I want a smooth migration with updating as few modules as possible in one batch. as a maintainer I want to do such cleanups as rarely as possible.
  • a
    We can leave the shims in for multiple major versions if we like. I think time is a better metric than number of major versions.
  • b
  • b
    an enahncement that adds the namespaced function, release that, and 9 should have deprecated the old functions
  • b
    cant we just backport that to 8.7
  • a
    I think that ship sailed, but we could get 9.0.1 out where the deprecations are ‘softened’
  • b
    we could do both?
1...514515516...643Latest