Allow disabling of the thread checks as a "migration" - a pattern we can re-use #5425
Conversation
…or using new `Migrations` area in the FyneApp.toml
| @@ -0,0 +1,5 @@ | |||
| //go:build migrated_fynedo | |||
There was a problem hiding this comment.
Maybe migrated_threading would be better? Calling it FyneDo sounds a bit non descriptive to me.
There was a problem hiding this comment.
I'd thing that "threading" is generic which is potentially problematic too.
The reasoning here is that the name matches an API that developers will have used to prepare this migration.
| @@ -4,3 +4,6 @@ | |||
| ID = "io.fyne.hello" | |||
| Version = "2.5.3" | |||
| Build = 2 | |||
|
|
|||
| [Migrations] | |||
| fyneDo = true | |||
There was a problem hiding this comment.
Same comment as further down. Maybe calling this threading = true would make more sense?
There was a problem hiding this comment.
That assumes we will only ever have one threading migration. I'd rather be more specific
There was a problem hiding this comment.
Hmm, true but I'm not all too enthusiastic about the previous name either. I would like to hear what @dweymouth thinks.
There was a problem hiding this comment.
If we are to do a v3.0.0, then we can remove the tag and use the same tag again in the future in case we want to do one more thread migration (which I kind of think is unlikely before v3.0.0). I am still in favour of migrating threads as a better name (fynedo sounds a bit strange) but I approved this for now so it can land and be useful for more people.
There was a problem hiding this comment.
Interestingly I think that re-use as you described would be a very bad thing. A migration system where what it means changes over time seems like it will be confusing and probably problematic.
Hence I'm happy we are sticking with what is here as it's explicit.
Good question. I wanted to do it here as one PR for discussion, will migrate to tools once agreed. |
|
FYI: With the last commit, the thread check lookup being variables means that stuff aren't optimized away any more. You could just revert that commit and use a |
|
@Jacalz i think it's good now? |
|
There is the naming discussion that I pinged Drew about still. |
There was a problem hiding this comment.
Let's just land this in the meantime. We can change the name in the future depending on what @dweymouth thinks about it.
Reasoning:
With this pattern we could (like the Go module tooling approach) change how apps work based on metadata, but build it in to the app through compiler flags.
Checklist: