Simplify namespacing and package naming to reflect current project realities
Closed this issue · 0 comments
The project namespacing and package naming has morphed several times over the life of the project, and at some point in prepping for the 1.0 beta, the names changed to insinuate a future where there could be dozens of data providers and delivery frameworks.
Then nothing happened on the project for almost 2 years.
The reality is that there are not likely to be other systems using this besides ASP.NET and ASP.NET Core. So segmenting for different types of "publishers" seems grandiose.
So I want to bring everything back to basics. We can learn from ecosystem improvements in the last 2 years and streamline everything to be intuitive and still allow for growth.
I believe the new structure should be as follows:
ASP.NET Classic
Microsoft.Restier.Core
Microsoft.Restier.EntityFramework
Microsoft.Restier.AspNet
ASP.NET Core
Microsoft.Restier.Core
Microsoft.Restier.EntityFrameworkCore
Microsoft.Restier.AspNetCore
Pros:
- You can add different targets and components without complicating the process. For example, Postgres can release their database support through
Postgres.Restier.NpgSql
without breaking the naming structure.
Cons:
- Too many variations on the different NuGet packages. We'll need to:
a) De-list any older Restier packages so they don't show up in the Nuget.org search results
b) Ask other people who have shipped interim packages in the ecosystem to do the same.