search

inexorgame-obsolete / deprecated-cube-engine-inexor

UNMAINTAINED: Please have a look at the vulkan-renderer
https://inexor.org
zlib License
11 stars 1 forks source link

Overall story: Rolling release system #400

Closed Fohlen closed 7 years ago

Fohlen commented 7 years ago

For the rolling release system, there's currently few things to be done

This will also close milestone 0.9.0-alpha (Speed Edition)

Croydon commented 7 years ago

Why aren't you using #37?

Fohlen commented 7 years ago

Because this is the overall story for 0.9.0 release, which all tickets should be closed before release.

Fohlen commented 7 years ago

I've also cleaned up the milestones on GitHub, please consider the current list at https://github.com/inexor-game/code/milestone/10 as locked. All the tasks should be done to a level where we can say they are acceptable as an experimental stage. Then go, release.

a-teammate commented 7 years ago

Aaah okay: this issue is meant to be a milestone actually :) We should make this page https://github.com/inexor-game/code/milestone/10 contain the info we have in this issue. So we need to create issues for the points you mentioned (and tag them).

aschaeffer commented 7 years ago

I don't believe we can deliver a rolling release system with 0.9.0. A lot of tasks have to be done until we get to this point. So this topic shouldn't the main focus of 0.9.0.

Until now the main focus were Flex, CEF and RPC/Tree, which are big goals already and all of them still needs work to be completed. I would suggest to focus on these and bring them into a stable state first before targeting another huge goal.

Croydon commented 7 years ago

1. Updating

So Inexor Flex is planned to update Inexor core. Flex can maybe get updated via a .sh/.bat file. How are we updating Node.js? NOT updating Node.js or expecting the users to do it manually is unacceptable.

2. Packaging problem

This doesn't fix the packaging problem for Linux or Windows (at all?). Quote Wiki: "built for Ubuntu 16.04 and Windows only for now" So it's highly limited on which Linux Distributations you can run it and we might get non producable "but it's working on my machine" bugs because of different Ubuntu versions AND we exclude all other Linux users which aren't Ubuntu users. Doesn't look like a solution. We are back were we started on Linux: Building for each and every distro binaries (not do-able) or exclude people (not acceptable). And if we are starting to build specific binaries, we could host distro specific files/repositories in the first place. Remember where we started this entire discussion?

Snapcraft as proposed by Fohlen previously or Flatpak (as favored personally be me #395) or another container-alike packaging format seems to be the only sophisticated, long-lasting solution on Linux. Everything else might improve a few things here and there, but is not solving it at the root of the problem, plus creating likely new problems on every step of the way. Snapcraft/Flatpak also having their updating services, solving the update problem as well. Also solving it in a widely adopted and tested way.

I'm sure we would find an good updating solution on Windows as well if we don't rush it. We are mostly a 4-core-team-member show and I feel sometimes like we want to do too much in parallel. Concentrating on doing it from the ground up might be better. Get our build system to the point that most people can easily build it, get out system to the point where everyone can run it easily, then get it packaged and auto updating for everyone. What we are doing right now in parallel is getting it build for some, have it complicated and error prone to run for everyone, and working on it to get it packaged for some.

3. End-user dependency

On Windows we seem to settle even more on Node.js/npm as an end-user dependency, right? (#364) How else should this setup work without a pre-installed Node.js/npm? And if we are starting again to ship Node.js/npm as we previously did with our platform repository (https://github.com/inexor-game-obsolete/platform) how are we supposed to update these via npm? (Back at problem 1.)

a-teammate commented 7 years ago

@aschaeffer

I don't think going rolling release is actually that far fetched. Yes, sure we had different plans for 0.9.0 but CEF, Flex and RPC/Tree are all more high-level features than the rolling release system is. Since we're working bottom-up it would make sense imo to tackle this first.

So the ordering is:

  1. make the build system more stable
  2. make testing / distribution easy (rolling release)
  3. add features and systems (CEF, flex, ..)
a-teammate commented 7 years ago

This issue is a duplicate, close. Everything else -> #37