dotdevelop/community

monodevelop fork long term architecture / roadmap

lytico opened this issue · 6 comments

lytico commented

discussions about architecture as a fork of monodevelop

lytico commented

suggestions from an insider (sender is known, but i don't want to make her/him public):

For the editor layer I would recommend switching back to an older version and start from there.
The visual studio infrastructure is not required and a problem.
I would suggest moving roslyn out of process like vscode and be flexible in the data structures the IDE uses and stick to the best/most efficient solution.
In general I would suggest cutting down features. Remove everything you think you don't need and add stuff as required.
For example: VCS support ? Mac related code etc.

  • 👍2
lextm commented

What I recommend,

Milestone 1

  • Revive 7.x release as that provides a stable starting point. I already have everything ready for Windows port, while I believe the Linux port is easy too.
  • Provide installation guide. Windows side I can ship MSI installers, while Linux side probably show users how to compile from source.

There isn't any tough task here, so I assume it can be done in just a few weeks.

Milestone 2

  • Fix known/unknown issues of 7.x release.
  • (#2, #6) Decide what new code editor to go to and integrate it with either 7.x or 8.x branch.
  • Ship a new release from there.

Milestone 3

  • Decide other features required by MonoDevelop.
  • Ship frequent releases with new features.

A few important items to be considered here,

  • Language server protocol support, so that Roslyn/OmniSharp can be integrated. Then MonoDevelop shares the same backend like VSCode.
  • (#3) Debugger adapter protocol support, and take over Samsung's .NET Core debugger. The former is already there in 8.x, so just need to be back ported. The latter hasn't been updated by Samsung for a while and is buggy on Debugger adapter protocol support. Once this is done, .NET Core support can be completed, and gives a solid ground for other tasks.
  • Evaluate new things done in 8.x releases and see how much can be reused. Unit testing based on VSTest can be a very useful example.
  • Migrate to .NET 5 should be an important task, as Mono won't be a focus of Microsoft/Xamarin again, once .NET 5 is out.

Things in parallel

  • (#1, #4) Take over homepage/brands/Linux package repo and other assets from Microsoft/Xamarin, so the community can release future releases under MonoDevelop name.
  • 👍4
lytico commented

Release 8.6 preview see here: #10

lytico commented

@lextm please make a suggestion which 7.x we should fork.
lastest 7.8 release was from here: https://github.com/mono/monodevelop/tree/monodevelop-7.8.4.1 ( https://github.com/mono/monodevelop/releases/tag/monodevelop-7.8.4.1 ) , as far as i can see.

lextm commented

@lytico Use release-7.8 branch is better. 7.8.4.1 is the last tag on that branch, which is the last release for 7.x.

FlaviusHouk commented

suggestions from an insider (sender is known, but i don't want to make her/him public):

For the editor layer I would recommend switching back to an older version and start from there.
The visual studio infrastructure is not required and a problem.
I would suggest moving roslyn out of process like vscode and be flexible in the data structures the IDE uses and stick to the best/most efficient solution.
In general I would suggest cutting down features. Remove everything you think you don't need and add stuff as required.
For example: VCS support ? Mac related code etc.

That sounds pretty well.
It would be quite well to work in the core IDE with general data structures not related to any particular language or tool. It will allow to work with any other tools for language analysis (maybe even not dotnet).