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?
On Tue, Nov 25, 2014 at 4:47 PM, Tim Penhey <tim.pen...@canonical.com> wrote: > 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: > > http://reviews.vapour.ws/r/531/diff/# > > 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 > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
