On Monday, October 24, 2016 at 12:53:50 PM UTC-4, Alex Schultz wrote: > > Yea it's not removed but it's about consideration for the end user and > how they will now be flooded with warnings unless they do a bunch of > configurations to silence them (bad UX and probably a bad idea) or > find all the instances of the deprecated functions and update them if > they can (also bad UX). It would have been beneficial to add when it > will be removed in such messaging to set expectations. >
I think this deprecation within 4.x is correct. Semver says that a function has to be marked as deprecated for at least one published version before it is removed in a new MAJOR version. Thus, it is marked as deprecated within 4.x of the module and will be removed at a future major release, presumably 5.0.0 (but maybe 6? difficult to plan these things ahead). The deprecation itself does not warrant a MAJOR bump, but the backwards-incompatible removal does. See http://semver.org/#how-should-i-handle-deprecating-functionality, and http://semver.org/#spec-item-7 and http://semver.org/#spec-item-8 specifically. > As an aside we recently got nailed when puppetlabs-ntp became no > longer puppet3 compatible on master prior to the new version being > released. As operators and developers, these incompatible transitions > really need to be well thought out on their impact. I can't count the > number of times we've been hit when someone decided to change their > gem (or ruby) dependencies mid release cycle and it breaks everything > even if we don't actually consume any code from that module. Sorry > it's a major pet peeve of mine when we have to drop everything and go > figure out who's doing breaking changes mid cycle and either pin or > find a work around because of backwards incompatibilities. > Ugh, you've got my sympathies about how ruby and its gems generally handle dependencies. I've gone round and round with gem authors about this before and it almost always falls on deaf ears (ex: https://github.com/guard/listen/issues/374). Puppet is not immune to making mistakes or challenging decisions with this loosely defined standard, but my experience has been that they hew closer to both the letter and spirit of semver, as described above, and far more frequently than other vendors. As Erik suggests, version pinning is suggested to avoid upgrades affecting you inadvertently. When you make a conscious decision to upgrade, then at least you are assured the behavior is in a window where you can discern if you want to commit to it or roll back until a later date. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/705f0cd6-66f7-4de5-bfeb-f68b9b55c5e8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
