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 <
henrik.lindb...@puppetlabs.com> 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 puppet-dev+unsubscr...@googlegroups.com.
> 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
ben.f...@puppetlabs.com

-- 
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/CACkW_L6qUnecc9p42ZVtodAQFmv21%3DcFgkSJ9iyhmUmxzuo%3DQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to