search

jack-pappas / ExtCore

An extended core library for F#.
Apache License 2.0
180 stars 32 forks source link

Supporting multiple versions of FSharp.Core #44

Open jack-pappas opened 6 years ago

jack-pappas commented 6 years ago

Issues like #39 and @wallymathieu's work in #31, #32 raise an important question: should ExtCore support/target multiple versions of FSharp.Core?

If not, what should be the policy for determining which version of FSharp.Core we'll target? How would we decide if/when to upgrade the version of FSharp.Core we're referencing?

Another way of looking at this problem: if functionality (types and/or functions) from ExtCore is determined to be useful enough to be merged into FSharp.Core, how do we deal with that in a way which causes the least amount of breakage / code changes for users of ExtCore?

Thoughts? @7sharp9 @vasily-kirichenko @dsyme @tihan

vasily-kirichenko commented 6 years ago

I think we should reference FSharp.Core 4.3.4 at the moment and probably - 4.5.0 soon (not now for sure because there is no FSharp.Compiler.Tools package containing F# 4.5 compiler yet).

jack-pappas commented 6 years ago

If we target FSharp.Core 4.3.4 -- how backwards-compatible is that? For example, if someone using ExtCore is using the latest VS2015 update and hasn't (for whatever reason) been able to upgrade to VS2017, would they still be able to use new versions of ExtCore targeting FSharp.Core 4.3.4? Is FSharp.Core 4.3.4 compatible with all versions of VS2017 (e.g. RTM), or does it require users to be running a certain update?

I'm not opposed to requiring a somewhat-recent version of VS / F# compiler to be able to use new versions of ExtCore, but I do recognize not everyone is able to run bleeding-edge versions of VS / F# and I'd like to maintain some[1] level of backwards-compatibility there so those users can pick up bug fixes and such.

[1]: I think the level of backwards-compatibility I'd like to aim for is something like: let's be backwards-compatible with versions of VS / F# up to the point where supporting an incrementally-older version would require a major maintenance effort or otherwise prevent us from properly supporting users running any more recent version of VS / F#.

wallymathieu commented 6 years ago

I don't think there have been any breaking changes in FSharp.Core (but we could check that using SynVer, but I think it is improbable given that there are test cases of the API surface.

I've not been able to install vs2015 from scratch, but perhaps an appveyor build matrix for a sample project that works in current extcore could be used to diagnose any such issues.

wallymathieu commented 6 years ago

Looks like @vasily-kirichenko has an open issue related to vs2015, perhaps he knows more.