Adapt has been largely stable over the last 5 years, with the bulk of effort going into either mycroft-core, or padatious (a c++ ML-based intent parser). Given this stability, it makes sense to finally make a push for 1.0, opening the way to begin development on 2.0, without the baggage of maintaining backwards compatibility.
As part of the effort to get to 1.0, we'll have 3 major workstreams
There are currently 4 open PRs, languishing as far back as 2017. We should be able to complete or close these out quickly.
There are currently 30 open issues against Adapt. I'd like to triage these on the following dimensions
- Needs reproduction
- Can't reproduce, won't fix
- Reproducible, won't fix
- Reproducible, scheduled|in progress
- Fixed
- Deferred post-1.0
I'd also like to add the label of Adapt: Road to 1.0.0 to each of these issues, once they've been triaged.
Speficially, how/why we're transitioning to 1.0.0 to stable/supported, what the future looks like for 1.x, and decide where to branch for 2.0 development.
v2.0 is not really at a point that's open to community input just yet. My goal is to get 1.0 to a stable state, to allow for 2.0 to break those APIs cleanly. The suggestions that we've heard so far I would consider candidates for a 1.1 branch.
I don't yet have a prototype for the internals of 2.0, just a rough mental model. Until I have that prototype functional, I'm not willing to commit to any externally facing APIs.
An alternative might be to fork to a different library for v2.0, and bring it back iff they seem compatible. As I'm considering internals that are not as cleanly synchronous as adapt is today, that might make more sense. I still see the value in closing out what has been a largely stable interface for 5 years and calling it such. What are your thoughts, @krisgesling?