Revisions and Commits
|D2147||R1031:cb70e1c26b6c Update godot to 3.0.6 and add C# support|
- Mentioned In
- T6778: Meta: Issues with Godot 3
- Mentioned Here
- D2147: Update godot to 3.0.6 and add C# support
There is no support for exporting 2.1.4 projects to 3.0 at this time. Support for this should come in 3.1, planned for release in a few months.
Does that not make this a really bad update? (i.e. you can no longer use your projects, but you can start again) :/
I do however think that once the exporter is available, there will still be users who want keep their projects at version 2.1.4 (legacy), as it may not be be a simple export process.
So perhaps it would be best to have two separate packages? I'm not sure what the standard is for these scenarios.
I think it's better to wait for 3.1 or wait until tool for converting 2.x project to 3.x available.
I think we ought to treat godot like a development library and split it into two packages: godot2, godot3, and godot aliased to v2 for now (and to v3 once it is backwards-compatible). Game developers frequently stick to a single major version of a game engine throughout a project (since the risk of breakage is high, and the projects are short-lived enough anyway), so it's disruptive to bump the version without a way to downgrade. At the same time, this is a rolling release, so I don't think the package meets users' expectations if it can potentially be months behind on major features (v3.1 has no predicted release date yet).
Version 3 relies on some libraries versions that haven't been officially released yet -> one more reason for waiting 3.1
I don't see any reason for having 2 different versions of godot engine in the repository. It's not like the version 3 would never be compatible with version 2 and version 2 would keep on receiving updates !
@kyrios123 fair enough, but as someone interested in starting up a 3.0 project it's a bit disappointing to hear that the packaged 3.x version is a ways away still. Fortunately they distribute nice statically-linked binaries that are easy to unpack and use, so it's not a big deal either way.
Could there be a separate/unstable repo of some kind for Godot 3 then?
I think that for a rolling release, the incompatibility between two releases should not be a reason to hold up the packaging of a highly-anticipated software version as big as this one. If it won't be packaged for a long time, should we suggest to users that they now use the website binary for 3.0 for now?
Another reason to waiting for Godot 3.1 is OpenGL 2.x support. Currently, the old support for OpenGL 2.x is missing in Godot 3.0.
@cflow I don't think it need separate package for Godot 3. It's better for people to use official binary from Godot's website for now. I'll quote on @kyrios123:
What's so wrong about suggesting at least "some" way to get a new release via packaging without forcefully upgrading 2.1.4 from updates? I thought having a package manager here was so we should_not_ have to mingle with binaries and such to get our software.
There is nothing wrong with that. I just have different opinion from you. I'm not the one who decide thing here.
Another approach that we can adapt for Godot is waiting for the new bullet library being released, and update the package. Let people who use Godot 2 from the repo download the old version binary from Godot's website.
If just unreleased dependencies/incompatibilities are the holdup, that is understandable. I just hope this doesn't require 3 or more months before it is finally in the official repositories. That's why I thought having an equivalent of a 'ppa-like' repository in Solus could work as a compromise to make 3.0 available for end users. But I'm not sure how this distro would feel about that...
Either way, looks like I'll just go with the binary for now.
This is not true, there is a Convert to 3.0 option in 2.1.4, apologies for the misinformation, but it is currently still WIP. I believe the plan is to finalize the converter in a 2.1.5 maintenance release. Still I think care should be taken in how/when Godot is updated to 3.x.
Although Godot is not packaged for a number of major distro's, the general action for those that do seems to be to package 3.x.x over 2.x.x, with a minority maintaining separate godot, and godot3, packages.
That said if we are waiting for updated dependencies (bullet, etc.) to be tagged, by all means I think it's worth waiting, but I don't think we should rely on being able to open a 2.x.x project in Godot 3 without some breakage. As far as I'm aware (and from some experience), this is uncommon with game engines. If you are working on a significant project I think it's likely you would use a custom build or binary of the engine, and only upgrade a major version if there was some major benefit in doing so.
There is a version 3.0.3 that is currently in RC2 and there is also a release candidate for the legacy version 2.1.5.
I guess the best is to wait for these versions to be released then decide if we still stay in 2.x for some time or if we switch to the 3.x branch.
Okay so guys any comment on this ?
In order to preserve current users from headaches and cry, I think we should follow the road of wisdom as some already suggested above and update to 2.1.5 when the stable build will be available and stick to 2.x until version 3.1 is released.
I think keeping the Godot version on 2.x makes it useless for most users and 3.1 is still likely several months away. Keeping only a legacy support build of Godot only caters to legacy users. If a package is to support legacy users it shouldn't be at the cost of not putting up a package for current users of Godot. Godot 3 is leaps and bounds ahead of Godot 2. I think the best solution is to change the name of the current Godot package to Godot 2 and make a new package called Godot 3. If you guys would rather not have multiple versions I think it's still better to just have Godot 3.
That's just my opinion though.
I agree it does seem a shame not to have Godot 3 considering the major advancements in the engine, but we also don't want to upset current users. I'd be interested to know how other distros have handled this.
Okay as requested patch for 3.0.4 has been submitted (D2147).
I let Triage Team decide what to do with it. I already gave my opinion on this.