New NuGet package names based on the new naming conventions

[attilah]

New package names for the packages which will not be separated into multiple pieces
Naming follows the new naming conventions
Package names no longer contains duplicated 'Orleans'

[attilah]

@dotnet-bot test bvt please

[veikkoeeva]

Aah, hey, now that we're on this patch, Microsoft.Orleans.OrleansSqlUtils would need to be Microsoft.Orleans.SqlUtils, but even better would be Microsoft.Orleans.AdoNetUtils and prepare to streamline mentions of SqlServer etc. to AdoNet where applicable in the code too (in a separate PR).

[attilah]

@veikkoeeva the packages which were not renamed as part of this PR is not renamed, since we'll separate it into pieces probably after Beta. They will be split into Membership and Storage in most cases so:

• Microsoft.Orleans.Membership.Sql
• Microsoft.Orleans.Storage.Sql

etc...

[sergeybykov]

I think @veikkoeeva is suggesting to name them:

• Microsoft.Orleans.Membership.Sql -> Microsoft.Orleans.Membership.AdoNet
• Microsoft.Orleans.Storage.Sql -> Microsoft.Orleans.Storage.AdoNet

Makes sense to me.

[attilah]

That naming would suggest to me that we're working with any ADO.NET provider, which is not the case.

[veikkoeeva]

That naming would suggest to me that we're working with any ADO.NET provider, which is not the case.

Is that opposed to sql? Arguably AdoNet is more to the point than sql as we're working on ADO.NET platform and support potentially any vendor that has ADO.NET implementation. It's also notable Orleans could use (in some deployments should) use other than SQL to work with the storage underneath ADO.NET. This would line the code better in the future so we could rename instances of SqlServer and Sql when we're really working with ADO.NET.

[sergeybykov]

Naming is hard. :-)
Looking again at the alternatives: "ADO.NET" isn't really used as a name in .NET anymore, it's really System.Data; "Relational" seems too broad; "SQL", while not ideal, now seems to me less controversial than "ADO.NET" or "Relational".

[veikkoeeva]

@sergeybykov I think it's always been System.Data (the namespace and associated libraries), but the architecture name is ADO.NET, as mentioned here, for instance. Or the the latest documentation here. I think this is what defines the underlying platform. I'm OK with even the current mixed bag, but I still think the most in line would be to call it ADO.NET. :)

[sergeybykov]

Okay, we'll go with *.AdoNet then.

[jdom]

Before merging, we need to reach some explicit decision on this, as the side-effects of blindly renaming are pretty bad. Here is some examples of what I mean: dotnet/aspnetcore#1222
And of course when searching for Orleans in nuget.org, you'll find tons of packages which are deprectated, intermixed with the latest ones, which creates a lot of noise. This is bad too, although at least a human decides what to do there.
I'm still on the fence of what we should do, but I lean towards not renaming... splitting packages is a different story, but blindly renaming to a slightly better ID I believe is just not worth it due to the side effects

[jdom]

And here is an open issue regarding the package rename feature: NuGet/Home#1590

[attilah]

@jdom PRI2 workitem for them and all connecting discussion is started years ago, I don't think that we should hold off this and waiting for a solution from NuGet. Once they've a solution, we can add that "compat" layer to our publishing strategy.

[sergeybykov]

Closing this because we plan not to change names of the existing packages.