TaskBuilder 2 release
rspeele opened this issue · comments
This is a follow up on #15 to focus on how we release PR #14 .
TaskBuilder 1.1.1 (I think) already fixed @forki 's errors, the ones that #15 was originally about. It is stable.
1.1.1 and 1.2.0-rc have the same features and performance characteristics. They use the same underlying code for bind, tryFinally, etc. The difference is that thanks to @gusty rewriting the builder classes, 1.2.0-rc should work with older versions of the F# compiler, and will also be compatible if future versions of the compiler revert the type inference changes that came with F# 4.1. See the F# compiler issue. I consider this change good but not urgent, so we have time to do this smoothly.
TaskBuilder 1.2.0-rc is "source compatible" with code written for earlier TaskBuilders, but not binary compatible. I.E. if you upgrade you shouldn't have to edit any of your code -- BUT you will have problems mixing the two .dlls in one solution. If you have one project referencing 1.1.1 and another project referencing 1.2.0-rc, you can't then reference both projects in your web app or whatever. I don't think binding redirects fix this.
I do agree that 1.2.0-rc should have been versioned as 2.0.0-rc. When I versioned it I was only thinking about the source compatibility not the binary compatibility.
I guess we could take route 1 or route 2. Either way, the next version I publish will be 2.0.0.
-
Publish 1.2.0-rc as 2.0.0. and have Giraffe coordinate with their downstream users so everybody updates TaskBuilder together. This keeps the code clean but will cause a headache or two downstream.
-
Revise 1.2.0-rc to include both builders, with the new @gusty ones in a v2 namespace. Mark the old builders as obsolete. This is messy but smooth as it would make everything binary compatible.
To elaborate on route 2, suppose you currently you reference TaskBuilder 1.1.1. Upon upgrading to 2.0.0, you would get warnings because you are using the obsolete builder in every file where you have a task {...} block. You would fix those warnings by changing open FSharp.Control.Tasks.ContextInsensitive to open FSharp.Control.TasksV2.ContextInsensitive. If you depend on a library that was written against 1.1.1, it will still work, because the builders in the old namespace still exist and there is no conflict between the two.
What's the preference of folks using this?
Isn't it possible to release a version 2.0.0 with slightly different namespaces, so if the end user is somehow accessing both versions everything works fine?
Yes, this is pretty much what "route 2" would be.
It's just a question of which is worse:
a. Changing the namespace for the V2 API
or
b. Dealing with a bumpy migration to V2
Very nice summary! I like both approaches and I'm open to apply both of them.
Only (minor) side effect of approach 2 is that when you mark the old builders obsolete I think it would be nice to presume that these obsolete builders will eventually disappear with a future 2.x.x release, which gives end users a smoother transition period to upgrade their namespaces to V2. However, if a 2.x.x release removes the old builders then it sort of doesn't make sense to have a single namespace called "V2".
Maybe approach 3 is identical to 2, except that the old builder's namespace will change to open FSharp.Control.Tasks.ContextInsensitive.Old and the new one remains open FSharp.Control.Tasks.ContextInsensitive.
I think that might work if we also change the DLL name, so that it's possible to have two TaskBuilder versions distributed with an app as two DLLs. Otherwise, code written against the old version wouldn't be able to resolve its class/method references against the new version DLL, with them having moved to another namespace.
Well, I've been dreading this and putting it off long enough, so it's time to wince and pull the trigger on 2.0.0.
The new code is under FSharp.Control.Tasks.V2 (e.g. FSharp.Control.Tasks.V2.ContextInsensitive).
This is what the the README now recommends.
The old code is under FSharp.Control.Tasks for compatibility.
Please open a new issue for each specific problem with V2.