[Beyond] Plugin compatibility

[alfonsogarciacaro]

As keeping beyond and main in sync it's becoming more difficult, Rust/Python are already in working state even if not perfect and I've lost touch with beyond branch, I'd like to make 3.7 the last minor version release for Fable 3 and focus on Fable 4 from now on. To convince users to move to Fable 4 we need to make plugins work. As far as I know, the most widely used are FelizCompiler plugins, in particular ReactComponent. I can think of two ways of making the plugin work:

1. Have a "clean cut": release Fable.AST 4 and a new Feliz version compatible with it. Fable 4 users need to use latest Feliz (not sure how it will work with other packages that have Feliz as transitive dependency). The problem is devs still using Fable 3 will get errors if they upgrade Feliz.

2. Try to make Feliz plugins compatible both with Fable 3 and Fable 4, this would require releasing Fable4.AST (or similar name) as a different package and let Feliz.CompilerPlugins contain plugins both for Fable 3 and Fable 4. These could be exposed through and alias in Feliz like:

type ReactComponentAttribute =
#if FABLE_COMPILER_4
    Fable4.ReactComponentAttribute
#else
    Fable3.ReactComponentAttribute
#endif

This may complicate things, but the benefit would be a new Feliz version can be released without fear of breaking Fable 3 apps. What do you think? @ncave @dbrattli @Zaid-Ajaj @MangelMaxime

Another problem is the "transition period": that is, when we consider the new AST is stable enough so it's worth to update Feliz and ask users to upgrade. The problem is usually after the new version is more used and we get feedback we usually discover flaws in the AST that needs to be fixed.

[dbrattli]

Sounds like a great idea. Fable Python will shortly be ready to be merged with main, and have its first beta/stable release. As for plugins I think 1) "clean cut" would be the simplest way to go (and max restrictions should be used to keep existing apps working), but I also think it's not for me to decide.

[MangelMaxime]

Hello @alfonsogarciacaro,

personally, I am in favour of option 1 - clean cut.

For me, it is kind of similar to the discussion we had with releasing Elmish 4.

Have a beta phase where we notify the maintainer that the Fable.AST package is going to change for Fable 4 and they should work on a beta version of their library for supporting it. And after a certain period of time, release it as stable.

If we don't do that, in the future we will need to release Fable.AST, Fable.AST4, Fable.AST5, etc.

As far as I know, the most widely used are FelizCompiler plugins, in particular ReactComponent

For the publicly available package, I think you are right (according to NuGet - Used by tabs)

[ncave]

@alfonsogarciacaro I have to agree with @dbrattli and @MangelMaxime on favoring option 1 (clean cut). A new major version allows for breaking changes in both Fable and Feliz, but of course there are trade-offs with either solution. Having a clearly documented migration path will help.