Theia Roadmap / Theia 1.0

#1

I’d like to start a discussion around updating/recreating the roadmap as I got recently asked about it.

People looking at the repo would like to get a sense of what is planned for the future to decide whether and when it’s time to use Theia. I think we should mainly focus on

  • hardening the plug-in system and support VS Code extensions

  • polish UX

  • improve performance

  • improve documentation

  • fix bugs

What other things would you like to see on the roadmap and/or are you committing to focus on?

Also we could target a Theia 1.0 release for next year, which will certainly help in adoption. (Related issue https://github.com/theia-ide/theia/issues/2980)

Thoughts?

[original thread by Sven Efftinge]

#2

[Rob Moran]

Eclipse adoption completion? :wink:

#3

I like these items, so like a stabilization phase? (+ the continuous work on plugins and the eclipse move).

#4

[Nigel Westbury]

I would like to have a road-map for the Git work (Git view, Git History view etc). A lot of work has already been put into this but there is a lot more potential work. For example:

  • support for different SCMs such as Mercurial

  • expand out the features to include stuff provided by vscode, code-lens etc

  • fixing some of the workflows, for example amending commits

I am happy to help out on this, but it is hard without knowing the objectives and having feedback on PRs (eg https://github.com/theia-ide/theia/pull/3438).

#5

[Gorkem Ercan]

We probably need time between the plugin work finalization and 1.0. How about a beta when plugin APIs are finalized and when the 1.0 is released?

#6

The SCM generalization as aell as the code-lens stuff would be covered by supporting the corresponding vs code extensions. +1 for a beta phase for stabilization. The plugin system will change a lot of things and has large surface, so that definitely needs time to mature.

#7

[Rob Moran]

It would also be useful to review the codebase for any APIs we expose (extension points beyond inversify, inheritance models, etc.) and stabilise + document them for a 1.0 release

#8

I think we should go for only making the plugin api public. We could add contracts to a few central extension APIs, too, but it will make future changes much harder. I don’t think things have settled enough yet.

#9

[Stephen Raghunath]

More tutorials and docs for builders for things like plugins, APIs, debugging, deployments, etc :slight_smile:

#10

I created the following milestone to be able to track the features as described in the latest dev meeting agenda which describes all features/improvements necessary for the 1.0.0 release.

I also created the necessary issues to track such features :slight_smile: