Skip to content

introduce new legacy_threading build tag, build is now migrated by de…#6255

Open
dweymouth wants to merge 2 commits into
fyne-io:developfrom
dweymouth:new-threading-default
Open

introduce new legacy_threading build tag, build is now migrated by de…#6255
dweymouth wants to merge 2 commits into
fyne-io:developfrom
dweymouth:new-threading-default

Conversation

@dweymouth

Copy link
Copy Markdown
Contributor

Description:

Introduces a new build tag legacy_threading and retires the old migrated_fynedo tag. Code will now build as "migrated" by default including with a plain go build.

N.B.: The corresponding change to build.go will need to be made in the fyne-io/tools repository to set the new legacy_threading tag when the fyneDo migration is explicitly marked as false in FyneApp.toml

Checklist:

  • Tests included.
  • Lint and formatter run with no errors.
  • Tests all pass.

@coveralls

coveralls commented Apr 7, 2026

Copy link
Copy Markdown

Coverage Status

coverage: 59.837% (+0.004%) from 59.833% — dweymouth:new-threading-default into fyne-io:develop

@dweymouth
dweymouth marked this pull request as ready for review April 7, 2026 14:28
@dweymouth dweymouth added this to the "H" Release milestone Apr 7, 2026
@andydotxyz

Copy link
Copy Markdown
Member

Thanks for marking this as 2.9 - the migration plan shows we need more serious warnings on the 2.8 release and then we can turn this on by default for develop after v2.8.0 goes out

@andydotxyz

Copy link
Copy Markdown
Member

On naming - wouldn't it be better to stick with the name we used before and pick "legacy_fynedo" I know it's kindof backwards - but then we have a process for future migrations whereby it's "migrated_xyz" followed by "legacy_xyz".

Or maybe "disable_" instead of "legacy_" or another name?

@andydotxyz

Copy link
Copy Markdown
Member

Oh, I misread the milestone - this needs to go to "I", as per the doc we have: https://github.com/fyne-io/fyne/wiki/Threading-migration

@andydotxyz

Copy link
Copy Markdown
Member

Feel free to pick this up now that 2.8 is out

@dweymouth

Copy link
Copy Markdown
Contributor Author

On naming - wouldn't it be better to stick with the name we used before and pick "legacy_fynedo" I know it's kindof backwards - but then we have a process for future migrations whereby it's "migrated_xyz" followed by "legacy_xyz".

Or maybe "disable_" instead of "legacy_" or another name?

If going with this naming scheme, "legacy_" is definitely better than "disable_" I think, because then it would be "disable_fynedo" which is definitely not what the tag would be doing. Even "legacy_fynedo" is not the most descriptive name since it doesn't change the behavior of fyne.Do per se, but the rest of the threading system. But I do see the value in using a patterned naming scheme like "migrated_fynedo" -> "legacy_fynedo". I wonder what others think?

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants