EntityFramework.* packages renamed to EntityFramework7.* & meta-package removed

[bricelam]

In Beta 6, the Entity Framework packages have been renamed to EntityFramework7.*. The meta-package EntityFramework has also been removed. For more information, see NuGet Package Naming and dotnet/efcore#2508.

This issue has been locked to avoid spamming folks subscribed to this repository. Please use dotnet/efcore#2508 for any further discussion.

Update (we reverted this change)

Thanks for all the feedback. We discussed this at length and ultimately decided to revert this change (thus removing the major version from the package names). While we have not been able to come up with any concrete scenarios where the major-version-in-name approach was broken, and there does seem to be value in preventing inadvertent upgrades across major version boundaries, we ultimately agreed that we shouldn't try and do anything special in EF to solve this.

BTW it is worth noting that providers may choose to still use a different package name for each EF major version (in fact some already do this for EF5/6). We will leave this decision up to individual provider writers to do what they feel is best.

[terryt2000]

omg, thank you! +1000

[scionwest]

Doesn't including the major version number in the package name defeat the whole point of using SemVer?

It always felt better to me just typing out the package I want, and not worrying about what version is in the title. I would think the major version of the package would be 7.0.0-beta6

[bricelam]

@scionwest I agree that it's a little unorthodox, but please read NuGet Package Naming for our rationale.

[scionwest]

@bricelam I did and I understand the point behind it. I had read elsewhere (or watched via standups) that you guys were wanting to use SemVer as your version spec for things. In this scenario, for all nuget packages, you're not adhering to that spec. Conditionally adhering to different specs makes versioning more complex than it needs to be.

Imo one spec should be chosen and used for everything. Either nuget or SemVer.

[LordZoltan]

Yeah, no, I agree completely with the rationale on this - ef7 is not ef6, and anybody accidentally upgrading from one to the other is going to get very confused - it's a defensive measure - but one I agree with.

[terryt2000]

@scionwest I don't read that as applying across all Nuget packages, just EntityFramework (although I might have missed something) The important piece here is allowing the coexistence of EF6 and EF7 in the same solution. This was a significant sticking point me having libs that use EF6 calling complex stored procs, and wanting to use Identity 3.0 with EF7. Had to do a bunch of workarounds to implement everything in EF7. Not sure it applies everywhere but it makes good sense to me here, and I honestly don't see where it introduces any complexity. As the post stated, upgrading major version #s should be a conscious decision, so groking the package naming is the least of your worries.

[akoeplinger]

I read your rationale and understand why you're doing it, but I feel like at this point the version number stops providing anything useful and you might be better off with EntityFramework2015 or even EntityFrameworkMagicUnicorn 😄

[Bartmax]

This suggests that EF7 is a different product than EF6. Which is kind of right, that's why there were some discussion about changing the name completely.

So talking about SemVer, which I agree with @scionwest I don't think they are breaking SemVer exactly but if the product name is EF7 right now, sticking to SemVer then you can versioning like EntityFramework7 : 1.0.0-beta6 (for example) instead of version 7.x.x, does this make sense?

So you can have, EntityFramework: 6.x and then EntityFramework7 : 1.0.0-beta6 (is like calling EntityFramework Sequel or 2, it doesn't matter).

With this, you can still have major releases and also breaking changes like EF7: 2.x when it makes sense OR if fits better to break lot of stuff and providers then you can roll out EF8, EF9, EFX (ala apple) using SemVer for all products.

When new 'version' of ef can be considered a new product? There can be a lot of things, but when you see that someone might want to use EFA with EFB in the same project I think that's a good indication of that. Like what's going on currently with EF6 and EF7.

What I see that can be confusing is this 6 - 7 thing. If this was EF and EFS or EFX or new name (which I do ask for consideration) wouldn't be a problem. But as soon as you start seeing EF7 (or EFWhatever) as a new product, this makes sense a lot.

[Bartmax]

EntityFrameworkReborn 👶

[terryt2000]

@Bartmax ugh, lol

[bricelam]

See also EF7 – v1 or v7? (especially the So, is it a v1 or a v7? section)

[daveaglick]

I think @Bartmax hit the nail on the head. The "6" vs "7" isn't being used as a version number so much as a product identifier. It's like with Windows 8 vs. Windows 10 - the latter is not merely a new version of the former, it's a whole new product. With that perspective, I think using the 7 (or 8, 9, etc.) in the package name makes perfect sense.