Revert System.Linq assembly version bump?

[justinvp]

dotnet/corefx#13726 added a new System.Linq API so the minor assembly version was incremented, but it sounds like the version change needs to be reverted according to @joperezr's comment: dotnet/corefx#13828 (comment)

cc: @ericstj, @JonHanna, @stephentoub

[ericstj]

That's the practice we've been following so far. If API is core only we don't bump assembly version. The logic behind that was that we didn't want Core defining what was in new assembly versions when those assemblies were also part of NETStandard.

Once we change to make netstandard not use contract assemblies and instead use NETStandard.dll we could revisit that POR (/cc @weshaggard), but until then I'd like to keep them the same. Only bump the minor version when NETStandard API changes.

[karelz]

cc: @JonHanna @OmarTawfik @VSadov

[JonHanna]

Any possible downsides to the reversion?

[ericstj]

You can run into ref-def mismatches in testing when the change is made if the test or any dependencies were compiled against the old package and using the new implementation. @karajas's recent work should alleviate this though since it runs all tests against the live build instead of mixing/matching.

[JonHanna]

Sooner the better then.

[justinvp]

@JonHanna, want to grab it?

[JonHanna]

I'm on phone right now, and it might be a few hours before I can.

[JonHanna]

To bring the details into this issue.

I created dotnet/corefx#14479 which had lead-balloon-like levels of success. There are a lot of dependencies on the current version. @ericstj commented at dotnet/corefx#14479 (comment)

These are ref-def mismatches in the final package set that will cause runtime issues. They're happening because each of these libraries is building against the old packages.

We could fix them all by adding p2p references but that is going to be painful.

I'm tempted to leave this as it is. If we want to make this change that will be much easier once dev/eng work is done.

And at that point I gave up on that PR.

[karelz]

Without understanding details ... it seems this issue should be blocking release. We cannot ship with current versioning. Is that correct?

[ericstj]

That's TBD. Most of these assemblies are becoming NETCoreApp specific now that the portable story is NETStandard.dll. Given that, we could decide to have the assembly versions be defined by NETCoreApp reference assembly instead of NETStandard reference assembly. I'd like to get @weshaggard's feedback on this since he's been driving this story so far. If we decide to let NETCoreApp define assembly versions then this will have the correct version.

[weshaggard]

The full end-to-end versioning story has not been fully worked out in practice yet. With that said I don't think there is any real concerns that I know that would hurt keeping the new bumped version for .NET Core in this case. My suggestion is to keep the version number as is (4.2) for now and only change it if and when we find a real issue.

[justinvp]

If we do end up keeping the bumped version number for this assembly, will we bump the versions of other assemblies that have new APIs, to be consistent across the board?

[weshaggard]

If we do end up keeping the bumped version number for this assembly, will we bump the versions of other assemblies that have new APIs, to be consistent across the board?

I would not do that at least not yet. I want to think of this as an exceptional case for the time being and stick to our guidance of not bumping the versions when only adding .NET Core specific APIs. When more of the versioning story comes together we might revisit.

[ViktorHofer]

So as the decision was to stick with the incremented assembly version I guess we could close this issue? @karelz @justinvp?

[karelz]

I let @weshaggard / @ericstj decide here.