Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve user-friendliness of project version mismatch message #79118

Merged
merged 1 commit into from
Jul 10, 2023

Conversation

aaronfranke
Copy link
Member

@aaronfranke aaronfranke commented Jul 6, 2023

Fixes #79095. EDIT: Updated the text to say "last edited" instead of "built", too lazy to re-take the screenshot.

Screenshot 2023-07-06 at 11 32 22 AM

Should be cherry-picked to 4.1, but it might be good to wait for translations to catch up?

Do not cherry-pick to 4.0, this code has changed between 4.0 and 4.1 to make space in the UI for labels.

@aaronfranke aaronfranke added enhancement topic:editor cherrypick:4.1 Considered for cherry-picking into a future 4.1.x release labels Jul 6, 2023
@aaronfranke aaronfranke added this to the 4.2 milestone Jul 6, 2023
@Listwon
Copy link
Contributor

Listwon commented Jul 8, 2023

_project_feature_looks_like_version(const String &p_feature) is very error prone solution and workaround for something that should be changed in the core. Just move editor version to a separate config variable. It is not a "feature" so it shouldn't be stored as such in the first place. Look at the PR that you've rejected #59975

@akien-mga
Copy link
Member

I tend to agree, it's not really a feature and we don't want it to be handled the same way as other features are handled - so that's a good case for a dedicated variable, which would also make it possibly more useful.

@aaronfranke
Copy link
Member Author

aaronfranke commented Jul 8, 2023

The project version has a lot in common with the feature warning system. Both should result in the project manager warning the user about the project using something the current editor does not have. Having it be just another entry in this array also means the user can pin to a more specific version, like 4.1.1 or 4.1.1.stable.official, due to this I would argue against replacing the version entry in the features array because we would lose the ability to have multiple values. The only thing that needs to be different is the message we display to the user.

@akien-mga
Copy link
Member

akien-mga commented Jul 10, 2023

See godotengine/godot-proposals#7254, which this might address.

Edit: Not fully, this still doesn't make a distinction between an upgrade and a downgrade. I think we really out to make better use of the info we have to give users some actually useful messages - an upgrade from 4.0 to 4.1 is different from an upgrade from 3.x to 4.x, and a downgrade from 4.1 to 4.0 is also something else.

Copy link
Member

@akien-mga akien-mga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not fully happy with the logic, I think it's a bit brittle and I don't like that we're reverse engineering metadata with heuristics when it's something that we wrote ourselves.

But that's a concern for improving this whole system further for a future 4.x release, for the immediate need to clarify the current warning in 4.1, this should do the trick.

@akien-mga akien-mga merged commit 349e440 into godotengine:master Jul 10, 2023
13 checks passed
@akien-mga
Copy link
Member

Thanks!

@aaronfranke aaronfranke deleted the friendly-upgrades branch July 10, 2023 15:37
@YuriSizov YuriSizov removed the cherrypick:4.1 Considered for cherry-picking into a future 4.1.x release label Jul 10, 2023
@YuriSizov
Copy link
Contributor

Cherry-picked for 4.1.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Misleading / unhelpful warning tooltip on 4.0 -> 4.1 upgrade
4 participants