New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New NuGet package names based on the new naming conventions #3544

Closed
wants to merge 4 commits into
base: master
from

Conversation

Projects
None yet
7 participants
@attilah
Contributor

attilah commented Oct 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@attilah

attilah Oct 13, 2017

Contributor

@dotnet-bot test bvt please

Contributor

attilah commented Oct 13, 2017

@dotnet-bot test bvt please

@veikkoeeva

This comment has been minimized.

Show comment
Hide comment
@veikkoeeva

veikkoeeva Oct 13, 2017

Contributor

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).

Contributor

veikkoeeva commented Oct 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@attilah

attilah Oct 16, 2017

Contributor

@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...

Contributor

attilah commented Oct 16, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@sergeybykov

sergeybykov Oct 16, 2017

Member

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.

Member

sergeybykov commented Oct 16, 2017

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.

@sergeybykov sergeybykov added this to the Triage milestone Oct 16, 2017

@attilah

This comment has been minimized.

Show comment
Hide comment
@attilah

attilah Oct 17, 2017

Contributor

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

Contributor

attilah commented Oct 17, 2017

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

@veikkoeeva

This comment has been minimized.

Show comment
Hide comment
@veikkoeeva

veikkoeeva Oct 17, 2017

Contributor

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.

Contributor

veikkoeeva commented Oct 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@sergeybykov

sergeybykov Oct 17, 2017

Member

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".

Member

sergeybykov commented Oct 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@veikkoeeva

veikkoeeva Oct 17, 2017

Contributor

@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. :)

Contributor

veikkoeeva commented Oct 17, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@sergeybykov

sergeybykov Oct 17, 2017

Member

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

Member

sergeybykov commented Oct 17, 2017

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

Attila Hajdrik added some commits Nov 3, 2017

Attila Hajdrik
Merge branch 'master' into package-rename
# Conflicts:
#	src/Orleans.CodeGeneration/Orleans.CodeGeneration.csproj
Attila Hajdrik

@sergeybykov sergeybykov referenced this pull request Nov 3, 2017

Closed

Store providers #3626

@jdom

This comment has been minimized.

Show comment
Hide comment
@jdom

jdom Nov 7, 2017

Member

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: aspnet/Home#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

Member

jdom commented Nov 7, 2017

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: aspnet/Home#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

This comment has been minimized.

Show comment
Hide comment
@jdom

jdom Nov 7, 2017

Member

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

Member

jdom commented Nov 7, 2017

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

@attilah

This comment has been minimized.

Show comment
Hide comment
@attilah

attilah Nov 9, 2017

Contributor

@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.

Contributor

attilah commented Nov 9, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@sergeybykov

sergeybykov Nov 28, 2017

Member

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

Member

sergeybykov commented Nov 28, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment