Christian Kaltepoth

Yes, that's how it is currently implemented. Unfortunately this isn't easy to change, because most state repositories also persist parameters only if the strategy is active.

The problem is that most `StateRepository` implementations will (AFAIK) only persist the strategy if the feature is enabled. Therefore, I don't see an easy way to fix this.

Hi! Thanks a lot for creating this PR. I just [stepped down](https://groups.google.com/forum/#!topic/togglz-dev/4eL0tAO3q-A) from my role as the Togglz maintainer and from being an active committer. But I hope that some...

I just mentioned your pull request in [my email](https://groups.google.com/d/msg/togglz-dev/4eL0tAO3q-A/fNIElN5tBQAJ) discussing the future of Togglz. I hope this will help to get more reviews. I'm really sorry for the delay, but...

Hey @hennr, regarding Sonatype OSS: I already requested to grant @bennetelli corresponding permissions to publish to the `org.togglz` group some time ago. See [this ticket](https://issues.sonatype.org/browse/MVNCENTRAL-5961). I could do the same...

> Maybe we can use the key from @bennetelli, if not I'd like to accept your offer to add my key as well :) BTW: The Sonatype OSS login and...

I think it really makes sense to think about a separate mechanism for this. It would be nice if one could register listeners at the `FeatureManager`. Something like: ```java FeatureManager...

@anandsunderraman Please note that even if this API gets implemented at some time, you may not get notified for every feature change. Users can always directly modify the feature state...

I agree with @edrex. These are two distinct use case. I like the suggested syntax. IMO this is much nicer compared to what #312 implements.

I'm basically +1 for this. Although we should most likely use RFC7396 instead, which obsoletes RFC7386.