Plans for releases

[thegecko]

With EclipseCon in a few weeks and the product beginning to mature, what are the teams thoughts on how and when we move to a 1.0 release?

We'd like input on the following:

• When should a 1.0 release be targeted?
• Should there be alpha/beta or preview releases beforehand
• How should pertinent bug fixes and features be tracked for inclusion (epics, GH projects?)
• What APIs need to be stabilised and how
• How will Theia be versioned (considering any APIs)
• What artefacts need to be delivered (docs, etc.)
• Any other considerations

From @svenefftinge:

I would like to understand what everyone expects a 1.0 release to be in terms of features, API contracts, project awareness. I.e. why do we want to have a 1.0 and when? I think that could be best discussed in a simple issue. From that we could agree on some date and then use a GitHub project to create the ramp-down plan.

@marcdumais @gorkem

[gorkem]

I do not think not having the 1.0 label is an important factor for adapters of the project but if we are going to put a stamp on it, I would like to see the API and extensibility stabilized and project structure and practices established.

Therefore, a couple of items on my wish list . Complete the move to Eclipse foundation and complete the plugin mechanism with the currently mapped out API set. I think we need to establish our regular cadence releases process before we do a 1.0. I like vscode's model of one feature release per month and as many bug fix releases as required. We can track the items that goes into a feature release on a GH issue as well. I think would give community a better chance to comment on the content.

[marcdumais-work]

So far there has no internal requests for a 1.0 release, on our side. I do not remember that the question was even asked.

Many good ideas suggested above. There is for sure a lot to do, and there is no huge rush, so we can take the time to do it well.

Additional thoughts:

• I would like for us to have better CI and automated tests, so that we are able to catch problems quickly, for example when a standalone extension needs updating because some core API changed, or when one of our Docker image is not working correctly. Part of the solution could be to improve CI for repos such as theia-apps and the various standalone extensions under theia-ide and eclipse GitHub orgs. Also improve the integration test suite we have in the main repo to cover more integration scenarios that are not easily tested at unit level.
• Improved "release engineering": invest more effort to prepare releases, so that they are as problem-free as possible. ATM we have an ad hoc approach, of releasing (as latest) whatever is on master a given day of the month. Maybe have a few days stabilization on a pre-release branch? We could also have some joint testing effort on that branch, during "freeze" period (the more testing is automated, the less would be left to do to validate a release).
• Debug is important internally, in general (DAP integration) and particular. Having a debug solution for a few of the most popular languages, such as C/C++, Java, TS/JS, golang, would be very nice (but not having them all is not necessarily a blocker for 1.0).
• Better language support: Some of the LS we use are in early development and will need a lot of improvements before being fully usable. The internal interest is for the usual suspects: C/C++, Java, TS/JS, golang

(update:)

• API documentation: We should have JSDoc on all API classes and methods, interfaces, .... While other types of documentation would surely be welcome, at least documenting the APIs seems mandatory.

[sr229]

In my opinion as a adopter of Theia, there are many bugs yet to be squashed to be able to be considered a 1.0. I logged some more issues and At the current state of Theia, it's not yet ready for 1.0, there are so many parts that needs to be ironed out.

It's not just the bugs, Theia at its state still misses some essential features. Like @marcdumais-work stated, most of the LS extensions for Theia is in WIP state, and its not yet considered stabilized.

[thegecko]

I've created a roadmap page in the wiki:

https://github.com/theia-ide/theia/wiki/Roadmap

What other major features should be considered for 1.0?

[sr229]

I vote for static content optimizations be included as Theia can be really slow to get the bundles compared to code-server (which they GZIP content, which currently we lack atm, and this can pose problems in slow networks).

[akosyakov]

1.0 was released: https://dev.to/svenefftinge/theia-1-0-finally-a-good-browser-ide-3ok0