Godot: add a new git label to mark back-portable cherry-pickable bug fixes for 2.x ?

[SuperUserNameMan]

Operating system or device - Godot version:

Issue description (what happened, and what was expected):

I know that the plan is to give-up 2.2 and to release some 2.1.x till 3.1 is usable.

Though, even after 2.1.x will be abandoned by the devteam in favor of 3.x, there will still be some game-developers that will continue to maintain the 2.x games they have already released as part of their "customer care".

Even though the dev-team have spent lot of time, energy and love on 2.x, it might still exhibit some issues for which a fix will be released during the 3.x era.

I'm aware that asking for the dev-team to provide LTS for 2.x is not a reasonable idea, and that if one wants LTS for 2.x, one will have to do it by oneself.

Though, maybe would-it possible to add some sort of git tags to mark issues and PRs that could or should be back-ported or cherry-picked to 2.x ?

This way, it would be easier to "unofficially" maintain 2.x even after the dev-team stops releasing official 2.1.x.
It would be some sort of "light-weight DIY LTS".

what do you think ?

Steps to reproduce:

Link to minimal example project (optional but very welcome):

[slapin]

Usually there is some grace period when some version is maintained. I think
for some time 2.1x will be maintained,
but after that everyone is encouraged to move to 3.x. In general this is
practice,
as development team is small. If somebody backports 3.x bugfix to 2.x, this
might be ported to 2.1x while it is maintained.
Otherwise, 2.1.x users are on theri own.

On Tue, Oct 11, 2016 at 2:39 PM, SuperUserNameMan [email protected]
wrote:

_Operating system or device - Godot version:_

_Issue description_ (what happened, and what was expected):

I know that the plan is to give-up 2.2 and to release some 2.1.x till 3.1
is usable.

Though, even after 2.1.x will be abandoned by the devteam in favor of 3.x,
there will still be some game-developers that will continue to maintain the
2.x games they have already released as part of their "customer care".

Even though the dev-team have spent lot of time, energy and love on 2.x,
it might still exhibit some issues for which a fix will be released during
the 3.x area.

I'm aware that asking for the dev-team to provide LTS for 2.x is not a
reasonable idea, and that if one wants LTS for 2.x, one will have to do it
by oneself.

Though, maybe would-it possible to add some sort of git tags to mark
issues and PRs that could or should be back-ported or cherry-picked to 2.x ?

This way, it would be easier to "unofficially" maintain 2.x even after the
dev-team stops releasing official 2.1.x.
It would be some sort of "light-weight DIY LTS".

what do you think ?

_Steps to reproduce:_

_Link to minimal example project_ (optional but very welcome):

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/6790, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAX0_d-GdgfYm8Ge86Vt19Lk0X7JJueks5qy3V4gaJpZM4KTiCD
.

[akien-mga]

A DIY LTS would be a lot more work for every user wanting to do that than porting their games to 3.x, so I don't think it would be necessary.

Also, commits that will be done in the 3.x era would likely be pretty hard to cherry-pick, as many things will be refactored internally (the most destructive change likely being an enforcement of some code style that we need to decide on).

So better help with the official maintenance of 2.1.x while it's supported, and then move on to 3.x once 2.1.x is no longer supported and 3.x has feature parity (especially GLES2-compatible renderer).

We're all talking of "breaking compatibility", but this concerns very small bits here and there. Porting a 2.1 project to Godot 3.0 or 3.1 would likely be a matter of hours. Way more time-effective than maintaining one's own branch for 2.1.

[akien-mga]

Also, identifying PRs that _could_ be backported would likely also be a lot of work, as most developers would be using 3.x / master and not particularly aware of whether a given changeset is cherry-pickable. Developers would have to try cherry-picking, see if it works, and then apply the label. After doing that much work, best push to the branch directly then :P

It was already becoming hard for 2.0.4 to know what changes could be cherry-picked, and I had to do a lot of trial and error and rebasing (and even failed at preserving stability, as 2.0.4 ended up with a regression that forced us to release 2.0.4.1), so I can't even imagine cherry-picking a commit made for e.g. 3.2 to 2.1.x.

[akien-mga]

Now, it's all a matter of resources. If some users have 2.1.x games in production and don't want to port them to 3.x no matter what, they are very welcome to organize themselves and provide LTS for 2.1.x officially for as long as they want :)

We can still accept PRs on 2.1.x even after its "official" EOL.

[akien-mga]

(Note: Feel free to delete the template messages in a new issue when they obviously don't match what you want to talk about :P)

[SuperUserNameMan]

Operating system or device - Godot version:

Issue description (what happened, and what was expected):

A DIY LTS would be a lot more work for every users wanting to do that than porting their games to 3.x, so I don't think it would be necessary.

I tend to think about 2.1 as an almost finished version of Godot, for which only few bugfixes would be required.

Indeed, for sake of backward compatibility, it would have to keep some ugly bugs (like the rotation trigonometry related bugs) that would require us to keep the workarounds we have already integrated into our projects.
But if no new features are added to 2.x, then 2.x is ALMOST finished.

3.x on the other hand will soon starts to exhibits its own new set of issues for which we will always have to wait for a next release.
And when new features will be added, there will be new set of issues again.

Today, 2.x still exhibits some bugs from 1.0pre.
Several of them are bugs and bugfix that have been postponed from version to version.
And 3.x is going to inherit them, and might also transmit some of them to 4.x.

TBH, my nightmare is : "waiting for Godot" .......... for ever :(
And i'm a little bit anxious to be forced to move to a new unfinished version when an almost finished version is available and would require little work to be polished.

Also, commits that will be done in the 3.x era would likely be pretty hard to cherry-pick

if these commits fix a bug that is already known to also exists in 2.x, maybe they could just be tagged 2.x-requires-backport or something ?
and concerned 2.x users could learn how to fix 2.x themselves by looking at how 3.x fixed it.

Porting a project to Godot 3.0 or 3.1 would likely be a matter of hours.

For small to medium projects that contain few to no workarounds, maybe.
But for bigger projects that contain many workarounds, how could we know ?
Maybe such projects will need to be rewritten from scratch for 3.x. ?

Also, identifying PRs that could be backported would likely also be a lot of work, as most developers would be using 3.x / master and not particularly aware of whether a given changeset is cherry-pickable.

Maybe concerned 2.x users could just give some feedback to the triage-squad into the related issue/PR ?

Now, it's all a matter of resources. If some users have 2.1.x games in production and don't want to port them to 3.x no matter what, they are very welcome to organize themselves and provide LTS for 2.1.x officially for as long as they want :)

I agree. Though, i wish that these efforts (if they are actually required) would remain centralized around the main Godot project.

TBH i don't know how many persons would be interested in a community maintained LTS 2.x. Maybe am I the only one ?

I'm just looking at the past of the Godot evolution from 1.0pre to the 2.2alpha, and trying to foresee potential incoming problems and ways to avoid them without adding too much extra work on the shoulders of the team.

And maybe, those little git flag i'm talking about could be a good investment just in case ... :-/

(Note: Feel free to delete the template messages in a new issue when they obviously don't match what you want to talk about :P)

Ok :o)

Steps to reproduce:

copy/paste ?

Link to minimal example project (optional but very welcome):

[akien-mga]

To be honest, you're completely overthinking what Godot 3.0 is about. It's not about rewrite the engine. It's about rewriting the rendering engine, i.e. 1% of the code. That might introduce some rendering-related bugs, that's true, but that will also fix a hundred of them at once.

Yes, Godot 2.1 is a well polished and stable engine. Godot 3.0 will be the same, and 3.1 even better, and so on. Porting projects from 2.x to 3.x won't be hard. I'll repeat it again and again, it's the exact same engine. Some stuff will change, that's why we bump the major release because "it won't necessarily run out of the box", but you clearly won't have to rewrite your projects from scratch.

[SuperUserNameMan]

I'm having bad feelings about the future trigonometry bugfixes, and about the COW mode changes.

[akien-mga]

Regarding the initial proposal:

• As long as 2.1.x is maintained, I prefer to do it by reviewing master commits in batches every once in a while than having to set a tag on every single PR without being sure it makes sense to cherry-pick it yet.
• When we'll stop maintaining 2.1.x, nobody in the dev team will have a clue if changes can be cherry-picked as the branches will have diverged way too much, so I don't want to impose such work on the bug triagers.

Thus, closing.