Roadmap to 1.0?

[arusahni]

Thanks for putting such a compelling library out into the world! As something like this would quickly become part of an application's core infrastructure, the "developer preview" state is slightly concerning as subsequent releases on the way to 1.0 could result in headaches for those using the library.

I was wondering if you could share:

1. What do you perceive as being the roadmap to 1.0?
2. How drastic do you predict potential API changes to be?
3. Do you have a general timeline for a stable release?

I understand that answers to the above are conjecture, and aren't commitments to a feature-set or timeline. Thanks!

[samscott89]

Hi @arusahni, thanks for the question! We completely understand that authorization is a critical component of the application and deeply embedded within it, so we take seriously the potential impact of any API changes on our users. As you point out, it's tough to answer your questions with total accuracy, but at a minimum we can give you the relevant context, the guiding principles we use internally and a sense for how we see things shaping up:

In answer to your questions:

1. There are a few main areas we are working on and have coming up
   1. Adding more APIs to our libraries to make it faster to add authorization features like roles (and other common patterns) and authorization-dependent UI elements to your application
   2. Providing more tools to help you automatically test policies
   3. Building out support for more languages and frameworks
   4. Continued bug fixes and stability improvements
2. API changes tend to be fairly stable after the first 1-2 releases of a feature. We may iterate on a feature in those first 1-2 releases based on feedback from users, but when we do so, we clearly call out the feature as such in the corresponding changelog (e.g., see list filtering in this changelog). We document all breaking changes in our changelogs (for example, here) and are available via Slack, Zoom and email to help you manage upgrades or refactors when needed (this hasn't been an issue for anyone that we're aware of).
3. We expect a 1.0 release in 2021. Barring major issues, changes, feedback (and all the usual caveats), summer/fall is a reasonable timeframe. I should note that we already have plenty of users running oso in production without fanfare. We've deliberately taken a conservative stance on version numbering and erred on the side of over-communicating with our users, though, in the interest of being transparent and building trust.

Finally, we do plan to remove the "Developer Preview" tag shortly. We included this when we first open sourced oso and were making major changes more frequently, but the library has stabilised substantially since then. We will continue to follow semver and stay at 0.x, and are happy to keep you posted on our plans as our work progresses!

[arusahni]

Thanks for your response, @samscott89! I'm looking forward to seeing where this project goes! 🍿