EntityFramework.* packages renamed to EntityFramework7.* & meta-package removed #42
Comments
|
omg, thank you! +1000 |
|
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 |
|
@scionwest I agree that it's a little unorthodox, but please read NuGet Package Naming for our rationale. |
|
@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. |
|
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. |
|
@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. |
|
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 |
|
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. |
|
EntityFrameworkReborn 👶 |
|
@Bartmax ugh, lol |
|
See also EF7 – v1 or v7? (especially the So, is it a v1 or a v7? section) |
|
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. |
|
I don't like this idea, either. I understand the interest in allowing multiple versions of EF to exist within the same AppDomain, but that has to do purely with the name of the assembly; not the package itself. I have always been a proponent of using --safe when updating packages, which should ensure that updating packages won't break the build. This is the entire point of SemVer, in that the version is semantic in its meaning. The fact that NuGet, and DNU by proxy, both update to latest by default is unfortunate. It should update to the latest safe version by default, which would allow SemVer to be used the way it's intended. Updating to an unsafe (latest) package should require an additional argument (like --latest) at the CLI, or an additional option in the package manager. Breaking the semantics to make it easier seems to be a crappy work around to the way most package managers work, including NuGet. This is a client issue, not an administrative packaging issue. I don't mind having meta packages if it makes it easier to find things, but that also seems to be a disadvantage in that discovery of newer versions of EF is also harder. |
|
No, it doesn't. If it's a different product, change the name entirely. It's not a different product, it's a reimagining of the implementation, but it's solving the same problems in a similar way.
Windows 7/9/10 is the version number, and is a marketing tool... Entity Framework isn't being marketed to consumers, it's a toolchain designed for smart people who should definitely be able to understand SemVer if they are trying to connect to a database.
|
|
We aren't really moving away from SemVer, but we are moving away from having every version of the product be listed as versions of the same package. I guess you could argue that technically our NuGet package doesn't really follow SemVer... but all up EF does. For example, we won't have v2 of EF7, if there are breaking changes to EF7 it will become EF8. I agree that having different packages isn't ideal... but it's kind of a side effect of how .NET and NuGet work. We want folks to be able to use two major versions side-by-side in the same project and we don't want folks to be inadvertently upgraded to a new major version (with breaking changes) when they upgrade their packages. |
|
I have read Naming article but I'm sorry to say I didn't find any good reason for that move. You build a whole new platform and versioning story around semver and you are the first to break it before it even ships. Nicely done. BTW: what is the next version going to be called? EF8 v1.0 ? EF8 v8.0? EF7 v8.0? That's non-sense. @terryt2000 I use Identity 3.0 as well, but I am not ready to take a dependency on EF7 yet. All you have to do is not use |
|
@rowanmiller Well yes you are breaking semver.
Guess what, semver defines something for that: a major version bump. Clearly you don't want to follow semver but make up your own system. Your arguments are very generic and could apply to any project... Imagine for a second a world where every package on Nuget follows the same system as you propose. Would that be good? If not what makes it OK just for you? |
|
@jods4 although i would also have liked if ef7 was given a different name, but come on their is still nothing to be so much angry about , and their is nothing that one should react like this. |
|
All this 'following semver to the letter' is great in theory; but I can tell you the majority of developers out there, using .Net (and also most of who, won't even be aware of ef7s existence yet) don't consider that a major version bump imp;ies breaking changes or, at least, loss of functionality either. |
I disagree. It's not a side-effect of how .NET and NuGet work. It's a side-effect of the design choice the ASP.net team have made on the overall product. I haven't personally done much with NuGet, so I'm not 100% sure on this. Can't you have different assembly names (ef6 & ef7) while keeping the same package name? I don't see how that causes conflicts with running different versions of EF side-by-side, unless NuGet isn't smart enough and just replaces the previous package of the same name. Eitherway, I don't think supporting side-by-side versions of EF is something that should be a goal here. You don't try and run the different versions of .NET in the same project (same solution sure; not the same project), nor have I ever seen anyone try to run different versions of the any other framework side-by-side in one project. This doesn't feel like a valid reason to break a spec. EF 6 to EF7 is not a whole new product. It's the same person, different clothes. EF7 with a SemVer of 1.0 doesn't jive well. SimVer spec reads as
This fits the bill of EF7. In response to @daveaglick
This is Apple and Oranges. The actual version number of Windows 8 is not, 8.0. It is 6.3. Windows 8 is a marketing name. You can apply "Entity Framework 7" in the marketing material, that's not the issue. When referencing it as a package though, it should follow the spec. "EntityFramework":"7.0.0-beta6" |
|
@shahid-pk No anger here. Just expressing my opinion that breaking semantics in this scenario is something I disagree with. |
|
@jods4 don't get me wrong, I'm definitely not suggesting that this is the ideal approach. The ideal would be that NuGet makes upgrading across a major version an explicit opt-in step and the CLR allows two versions of the same product to be used within an app. I also realize I'm probably not going to change your mind... but here are a few thoughts.
I think there are two aspects we're discussing here - product versioning and installer/packaging. And I agree that ideally they would be the same thing. http://semver.org doesn't have any hard guidelines around how a product is distributed or packaged. EF6.1.3 is a patch release with no breaking changes compared to EF6.1.2. EF7.0.0 is a breaking change release compared to EF6.1.3. EF7.0.1 will be a patch release with no breaking changes to EF7. This all clearly follows the guidance of SemVer. I don't think the fact that EF6 and EF7 are different NuGet packages means we are ditching SemVer altogether. |
|
@shahid-pk sorry if it came out very angry, which I'm not. BTW I'm not a native English speaker. In the end, it won't make a big difference, for me anyway. I'm going to reference the EF7 package and that's it, not much changed. MS has a long tradition with versioning problems, I guess old habits die hard. I mean just look at the .net version numbers there's just no sense behind them. Maybe calling EF7 something else would have made more sense. Saying you're going to create your own versioning scheme by moving the major version number from the "version" to the "name" is just weird. |
|
@rowanmiller You're package version or EF 7 is not 7.0.0/7.0.1 though. It is 1.0.0, which does break the SemVer spec. I completely agree with:
That was one of my points. Your nuget package is still 1.0.0 though, which doesn't fit what you just described. |
|
Hey,
~Rowan |
|
Hey guys, This is an announcement repo which many people are watching and maybe you should move the discussion into https://github.com/aspnet/EntityFramework/issues instead? |
|
@rowanmiller Ah, well some how I missed that. The major version being the framework name still bugs me but not nearly as bad as resetting the version number like I originally thought was happening. Thanks for the clarification. |
|
@ErikEJ - well, then if parrallel development is going to continue for any length of time, then I guess I will be looking forward to EF 6.9.99.999 ;-) But... I am sure we are all smart enough to deal with it, even if doesn't suit our delicate sensibilities... Right, off to deal with more important problems.... |
Yu want NuGet to install 2 versions of the same package into a project? Can you give examples of other package managers that do that by default? How does apt-get do it? gems? Do they all support this? |
I don't know if we'll get to EF6.9, but we may. I doubt we'll release 999 patches on the 99th minor version though. Seems much more likely we would have released 6.10.0 before patching the thing that much 😄 |
|
@rowanmiller - And then the arguments would start that it is breaks some Feng Shui like concept and a proportion of people would be offended... maybe release notes should also be Haiku... 😄 Anyway, really have to go and do something useful - best of luck to all, and don't get too stressed... |
|
62 e-mails to my inbox in just over 24 hours. I thought that this was the ASP.NET Announcements repo, not the ASP.NET Bikeshedding Debates repo. Please everyone - take it to the appropriate repos, not this. I need to unsubscribe if this continues. I just want to know about changes, not how everyone feels about changes! |
|
That's not entirely true. NuGet does have range identifiers, just not through the UI (as far as I know). You use a square bracket for mutually inclusive and and parentheses for mutually exclusive: For example: [1.0,2.0) That would include all version under 2.0 but greater or equal to 1.0. On Jul 15, 2015, at 9:13 AM, artganify <notifications@github.commailto:notifications@github.com> wrote: This whole discussion is extremely stupid. I don't really care about EF7 The real problem here is nuget. The whole thing has some really major My suggestion: Make a step back, rethink the whole thing again and talk with the guys — |
|
Here's what I suggest per Dave Glick. @davidfowl, @bricelam, and @DamianEdwards I hope you're listening. When you announce stuff here in the future
I subscribe here to see what changed. I literally, completely, totally care 0% how people feel about the changes in the context of this repo. I would like to see the discussions and debates in the relevant repo. Just think of the hordes of people who follow the EF repo who have no idea that this debate is raging on right now. Thanks for listening. |
|
@Ironyx Is absolute right. I'm honestly ready to unsub from this repo because of the couple of threads like this that have exploded into a million email notifications |
|
You can unsubscribe from the single thread. |
|
@rowanmiller the thing about the unsubscribe button is: it is not working at all. You still get your activity feed spammed and e-mails about every single response. I've cried at GitHub plenty of times about this problem but they never responded. Other than that I completely agree with @Ironyx |
|
This should work for versioning but not sure if this will solve the same package installed at different levels. Not sure if assembly redirection would work but I know nuget can add that in to web.config or app.config. Probably best bet is to break them up since they do seem like separate products at this time when you compare feature levels. Just my 2 cents. Get-Project -All | Add-BindingRedirect package id="SomePackage" version="2.1.0" allowedVersions="[2,3)" |
|
I think there might be a technology solution to the inbox issue. |
|
NuGet already supports constraining version upgrades: http://docs.nuget.org/Create/Versioning#constraining-upgrades-to-allowed-versions |
|
@csharpfritz exactly. This is enough to solve this specific issue. |
|
@artganify as @csharpfritz has pointed out - this can be achieved. Though the tooling support for upgrading to a major NuGet version can be improved, I'd wager the desire to run both EF6 and EF7 side-by-side is the main impetus for this change. I mean, really, who "inadvertently" upgrades EF? Anyway, it's unfortunate this SxS requirement has been given such precedence but the renaming seems like the most logically choice and from the links already provided it appears the EF team have been mulling this over for some time. |
Most likely to happen when someone is using EF6.1.3 and we release EF6.2.0. They run |
|
BTW I should add that everything being discussed here is exactly the conversation we had internally when talking about this change. Academically it feels wrong to use a different package name for different versions. But pragmatically it works - always upgraded within you major version, explicit step to swap to a new major version, ability to run multiple major versions side-by-side. |
|
@rowanmiller IMHO a message indicating the major breaking change and guidance on how to undo and upgrade to 6.2 as you succinctly put it would have sufficed. Running That SxS requirement though. Ugh. Anyway, keep up the great work, looking forward to all the new bits. |
|
I agree with you Rowan. To me, naming/versioning conventions are important only to the point where they communicate clearly enough to be understood and don't provide obstacles to solving problems. I don't really care about the package names themselves as long as they are documented. As @mcquiggd, so eloquently put it above "I am sure we are all smart enough to deal with it, even if doesn't suit our delicate sensibilities..." or we wouldn't be here in the first place. Thank you and the team for providing a solution to a problem (major versions side-by-side) that might not be ideal in a perfect world, but exists for many devs who want/need to incrementally port asp.net solutions over to EF 7. |
|
For the sake of keeping this thread up to date... discussed with @csharpfritz offline and agreed that it's not because NuGet doesn't support constraining to major version... it's just not the default experience (and the default experience will be the experience for 90-something-percent of our customers). Maybe we can improve that in the future and then we can always add 7.x.y versions of the main EntityFramework package that just pull in the required components. |
I hope thats not the end of the story, the people who know how to add a constraint are not the folks getting bit by an inadvertent upgrades to a new major version. One could argue nuget should add the constraint when installing packages, or even interpret a dependency version without constraints as having the same major version constraint by default. as @rowanmiller points out:
The nuget UI should warn that the displayed version is a major upgrade and maybe do a better job at showing not just the latest version in the updates tab but all newer versions. The command line could translate latest to mean latest within major version, inform there is also a major version update and use a force flag to upgrade to that. Now the user story on the commandline is the opposite of this. |
|
If the nuget UI was open sourced, this would already be fixed :) |
|
I don't get the whole chatter about improving NuGet. Improving NuGet tooling can happen, it should happen, and it probably will happen. The point still remains there is a desire by many to run EF6 and EF7 SxS with and without feature parity. As long as that continues to be on the agenda the name change is inevitable. I wonder how many people would still consider pulling in a second ORM into an EF6 solution if it was called say... NTTFx. |
|
Because its a package manager problem, upgrades from EF7 to EF8, EF9, EF10 will no longer be discoverable through nuget in the future. Installing a major version for EF using nuget works completely different then packages without SxS requirements. Changing the name because it works right now feels short sighted and sets a precedence for packages, EF being the popular package that it is. In the interest of all those subscribed I'll drop it though. |
|
Could you please move this discussion somewhere to https://github.com/aspnet/EntityFramework/issues |
|
This issue has been locked to avoid spamming folks subscribed to this repository. Please use dotnet/efcore#2508 for any further discussion. |
|
Hey All, 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. ~Rowan |
and others
In Beta 6, the Entity Framework packages have been renamed to
EntityFramework7.*. The meta-packageEntityFrameworkhas 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.
The text was updated successfully, but these errors were encountered: