-
Notifications
You must be signed in to change notification settings - Fork 344
What is the criteria of graduation from corfxlab? #134
Comments
Good question. I have not thought about it. @terrajobst, @richlander, @joshfree, any opinions? |
@ianhays is going to be open sourcing Microsoft.Expermiental.Collections to /dotnet/corefxlab very soon. |
Heya @codekaizen, I wrote this last summer! Now that I'm back at Microsoft I'm planning on moving this along closer to the core repo but there's been some discussion as to where it should go. Our options are to put it either:
The home for the MultiDictionary ultimately depends on how out of the park it is; corefxlab was designed for ideas that were may not make it to the main repo and that are in the more distant future. @terrajobst and I discussed this and were leaning towards just branching it off of master as an addition to System.Collections.Generic, but that decision isn't set yet. Regardless of where it will be, you can expect to see it somewhere soon :) |
@ianhays - glad to see you back! I'd agree with the sentiment that MultiValueDictionary doesn't seem too far astride of core collection classes, and having it in core would be unremarkable. A branch seems reasonable, but then my question becomes - "what becomes of the branch"? Even if it is merged to master at some point, the current availability of it as a separate package, which has good value for users not running Core, will be lost. |
@codekaizen Sorry for the delay; it's been real busy around here! I decided to put it into CoreFXLab for now and just pushed a PR #370 where we can continue iterating on it until it's ready for CoreFX. For now it is in it's own assembly: System.Collections.Generic.MultiValueDictionary. I tested it with some console apps running on the core framework and it works as expected.
It's been months but I'm honestly still not sure that I have a good answer to this. In it's current home in CoreFXLab it can easily be built as a desktop NuGet package since it is standalone, but once it is merged into CoreFX it will be jumbled together with the other Collections classes. We could always keep a desktop copy of the nupkg that only contains the MVD and push package updates that way. Although that would be the simplest solution it would require effort to maintain two copies of the same MVD code and subsequently be prone to error or stale versions. Another concern is if the CoreFX MVD evolves to depend on something that doesn't exist in the Desktop framework - what do we do then? How do we prioritize changes and updates to the MultiValueDictionary between Desktop and Core if they diverge and what does that look like? To answer the original question: the members of CoreFXLab are primarily focused on eventual inclusion into .NET Core so for now I'm going to keep with that focus and consider the "graduation" to be merging it into CoreFX as a part of System.Collections.Generic. |
@ianhays Doesn't the same apply to System.Collections.Immutable? That one is in CoreFx and the nupkg works on Desktop. |
Yes, but it is slightly different since Immutable is a standalone library whereas MultiValueDictionary would be built in to System.Collections.Generic. Of course I suppose I could just add a System.Collections.Generic.MultiValueDictionary.Desktop.csproj that only pulls in the MVD files from Open to build the Desktop version and nupkg that only contains the MVD. |
Hi, are there any plans to include the MultiValueDictionary in the BCL or as a (non-prerelease) nuget? |
There are no plans to do that. It's archived. See #2245 (comment). @ahsonkhan @KrzysztofCwalina This issue probably should be closed. |
Oh well, thanks. |
Microsoft.Experimental.Collections has a useful implementation of MultiValueDictionary, but it now appears abandoned in alpha state. A discussion on corefx indicates corefxlab is a good place for it, but what is the process to bring it to release from here?
The text was updated successfully, but these errors were encountered: