Pre-Alpha 3 Framework Enhancements

[sebinside]

Description

This issue can be understood as a meta-issue to discuss the current development progress regarding our roadmap and the last pre-release version.

Since the implementation of the new plugin-format, there shouldn't be so many major framework changes left. We should discuss the last open points to be ready for alpha.

Open points

• The plugin-format is already implemented, thanks to @daniel0611
• Build-environment rework. Right now, the build environment is only optimized for framework- and platform-devs. I am looking for a way to enable plugin-devs having an easier workflow without having to build everything by themselves. One approach could be to hand over a build framework and the api as source using proper sbt tasks. Another approach would be to use proper shell scripts.
• Speaking of which: Shell Scripts for installing the environment. We have quite an interesting number of separate projects and artefacts right now, the complexity should not be the problem of the plugin-dev or enduser
• Versioning: There are a lot of different versions right now. API Version (3.0), Framework Version (0.3), REST-API-Version (0.3), GUI-Version (0.3), npm-package version (0.3.4). We should discuss how these belong together, and how we increment them, also regarding later alpha and beta versions
• Documentation: Last but not least, documentation. @joblo2213 already started documenting chat overflow in more detail, we should finish this before the first alpha is released
• Marketing: I plan to start a youtube series to document the development progress and show the project to the world. Even right now, a number of creators knows what we are doing and are waiting for us to release. There is a market for this software, definitely.

Everything else

Besides this, there is a GUI to develop, more platforms to integrate and more example plugins to create. But I see the TODOs mentioned above as more crucial to the progress, right now.

References

Just referencing some issues here, which should be solved until the next release: #79, #63, #70, #40, #38, #22, #21. But of course, every issue solved, is good.

[sebinside]

As discussed:

• For "real" platform or framework developer, we should offer install scripts (Add bash scripts for framework setup #63)
• We should clean up that /project-folder (Refactor build environment #21)
• Endusers get deployed version with bootstrap launcher and jars
• Plugin devs get the same deployed version with additional sbt files for plugin development (after Refactor build environment #21)

So, the last undiscussed point is proper versioning. Any ideas?

[J0B10]

To be honest I don't care at all about version numbers. 😅

As we are having all these in different subprojects that are more or less individually developed it makes somehow sense to have individual version numbers for all of them.

But as they are all always destributed together and have the same release cycle we could also have one versioning system for all of them which would have the benefit that it is easier to understand for the end user but it is less flexible.

We just have to decide what we want to use. ¯\_(ツ)_/¯

For the api we propably should use Semantic Versioning as we later may want to deploy to maven central (see: maven central requirements).

[sebinside]

Okay then let's use semantic versioning on the API starting with Version 3 for the last pre alpha and 4 for the first alpha, coming soon after this. All other versions are Updated to this.