<div dir="ltr">I like the idea. Thinking out loud: do we want to combine this with "the wrench" so that we have 1 consistent way to fiddle with Juju behavior?</div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Nov 25, 2014 at 4:47 PM, Tim Penhey <<a href="mailto:tim.penhey@canonical.com" target="_blank">tim.penhey@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all, There are often times when we want to hook up features for testing that we don't want exposed to the general user community. In the past we have hooked things up in master, then when the release branch is made, we have had to go and change things there. This is a terrible way to do it. Here is my proposal: <a href="http://reviews.vapour.ws/r/531/diff/#" target="_blank">http://reviews.vapour.ws/r/531/diff/#</a> We have an environment variable called JUJU_FEATURE_FLAGS. It contains comma delimited strings that are used as flags. The value is read when the program initializes and is not mutable. Simple checks can be used in the code: if featureflag.Enabled("foo") { // do foo like things } Thoughts and suggestions appreciated, but I don't want to have the bike-shedding go on too long. Tim -- Juju-dev mailing list <a href="mailto:Juju-dev@lists.ubuntu.com">Juju-dev@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju-dev" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju-dev</a> </blockquote></div> </div>