I like feature flags so am +1 to the overall proposal. I also agree with the approach to keep them immutable, given the stated goals and complexity associated with making them not so.
I think the env variable implementation is ok too - this keeps everything very loosely coupled and avoids polluting a juju environment with an extra config attribute. On 26/11/14 08:47, Tim Penhey 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
