Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FeatureToggle V5 Roadmap #155

Open
jason-roberts opened this issue Feb 15, 2018 · 6 comments
Open

FeatureToggle V5 Roadmap #155

jason-roberts opened this issue Feb 15, 2018 · 6 comments
Milestone

Comments

@jason-roberts
Copy link
Owner

This is an overview of the potential themes for v5

  • Move to "pure" .net standard implementation
  • Move to .NET standard 2
  • Simplify configuration (try and have a single method regardless of platform: UWP, Core, Full. etc)
  • Simplify solution in visual studio (e.g. remove multi-targeting and have a single .NET standard class lib)
  • Maybe take the opportunity for a major release to re-examine the architecture of providers and how toggles are read
@jason-roberts jason-roberts added this to the Version 5 milestone Feb 15, 2018
@mikanyg
Copy link

mikanyg commented Apr 21, 2018

If you are going to change the provider model, I'm very interesting in your future thoughts. I have created 3 provider so far FeatureToggle.Azure and have some opinions on the matter.

@jason-roberts
Copy link
Owner Author

Thanks @mikanyg any thoughts gladly accepted :)

@mikanyg
Copy link

mikanyg commented May 16, 2018

It would be nice to know if any breaking changes was planned. But in general I think that having a good provider model is a way to have even more provider projects/packages being developed.

Some thoughts on the existing providers:
The SqlProvider should be greatly enhanced. It could support other than the boolean flag and the Sql should not go in the config by default.
The RavenDb provider and even the JsonEnabled could be moved to seperate Provider packages. Kinda like Serilog has many sink packages.

Finally if some management web ui could interact with the flags via the centralized providers (not the ones in config files) would be really cool. Inspired from the way HangFire (Background Job Scheduler) has both core packages, providers and a management UI package.

@jason-roberts
Copy link
Owner Author

Thanks @mikanyg - I appreciate all those suggestions. This library embraces semantic version so version 5 will be allowed breaking changes, I thought about the separate provider packages thing before so any suggestions on how to implement this are welcome :) I'm also happy to talk about modifying the SQL stuff.

One thing that's always been out of scope has been the management of updating toggles (e.g. web UI). This is something that I'm open to in the future but probably a good idea to focus on v5 first and then have another think about it.

@ardalis
Copy link

ardalis commented Apr 9, 2019

Are you still actively maintaining this project, @jason-roberts ? Looking for a library to use for a client.

@ardalis
Copy link

ardalis commented Apr 12, 2019

bump

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants