Would it be possible in this scheme to mark strict mode per class? I could mark my own code as being strict and therefore get compile time failures when I make a typo myself, but wouldn't have to enforce that on all third party code.
On Mon, Feb 22, 2016 at 4:47 PM, Henrik Lindberg < [email protected]> wrote: > Hi, I am thinking ahead a bit regarding puppet 5 and how we should deal > with all the requests for features that require deprecations. (There are > some related things like requests for additional validation and warnings > that are different from deprecations). > > In the past we merrily started issuing deprecation warnings, but the > community pretty unanimously said "stop doing that" we cannot deal with all > of those warnings. Since then we then pretty much stopped doing deprecation > warnings. > > There has also been a long standing wish for a "strict mode" in puppet, > that like a harsh teacher would point out every itty-bitty problem. > > So - what should we do? > > In PUP-5889 I have described an idea. This is the text from that ticket > as it stands right now. > > PUP-5889 > --------------------------------------------------------------------- > Add a flag --strict to puppet settings. When in effect this will turn on > --strict_variables, and will also enable other "helpful" but undesirable > behavior. (Each such behavior to be defined in a separate ticket). > > The semantics of this flag should be: > > * '--strict=ignore'; no strictness checks are to be performed, nothing is > reported. > > * '--strict=warn'; strictness checks are performed, they are reported as > warnings, individually configurable warnings follow their own setting (i.e. > if they are added to disabled_warnings). > > * '--strict=errors'; strictness checks are performed, they are reported as > errors and stop the execution. Further configuration to error individually > is not supported. > > When we add this we promise to not change the set of things that lead to > warning/error in .z releases, but we reserve the right to do so for .x > releases. The idea being is that you can safely accept updates for .z > without having to do anything. For .x releases you may need to step back to > '--strict=warning' and then correct the problem before going back to > '--strict=error'. > > This scheme should cater to those that are pedantic about following best > practices and not using deprecated features while those that only care at > major version boundaries can do so in peace without being bothered with > lots of deprecation warnings. > ---------------------------------------------------------------------- > > What do you think about this idea? Control all strictness and deprecation > warnings/errors with one flag, and handle individual ones (where > applicable) by disabling those checks. > > The benefit for us developing puppet is that we can introduce the new > behavior much sooner and we do not need to add flags for each and every > kind of validation/deprecation. This means we are more likely to improve > things as we are not holding off until the very last release in a major > series (and where inevitably some tickets will not make it). > > Ironically, if this feature is liked it will make it into 4.5.0 which may > be the last in the 4.x series, but no decision has been made yet. > > - henrik > > -- > > Visit my Blog "Puppet on the Edge" > http://puppet-on-the-edge.blogspot.se/ > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/naga6d%245r3%241%40ger.gmane.org > . > For more options, visit https://groups.google.com/d/optout. > -- Ben Ford | Training Solutions Engineer Puppet Labs, Inc. 308 SW 2nd Ave Fifth floor Portland, OR 97209 509.592.7291 [email protected] -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CACkW_L6qUnecc9p42ZVtodAQFmv21%3DcFgkSJ9iyhmUmxzuo%3DQw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
