Please document a release and patch cycle and make builds available.

[NetTecture]

As a core user I start feeling like I live back in 1990 - with no proper release strategy. This is bad for thigns like ASP.NET core but it gets realyl bad for EntityFramework where there are a TON of regrssions and issues for more than trivial cases around. Anything except the most trivial SQL is currently bound to run into breaking issues at some point. So, getting bugs fixed is pretty mandatory.

• Current release is 2.1.1. Nice. It is quite old.
• There is a 2.1.3, 2.1.4 and 2.1.5 release planned, but basically hardly anything happens there (2.1.3 has 12 closed bugs). Nice enough, 2.1.2 seems to have gone missing.
• 2.2 is getting out somewhere this year, which means months before production use. This would be nice, except that this one also looks abandoned now with the last update 20 days ago. So, if no active development happens here, how is that supposed to go in production? Interesting enough 2.1 has the last commit 13 days ago, but then where are the patches? When will this be released? Let me see.... NO ROADMAP, no release plan.

With the current release, as someone who has to deliver, I mostly look forward to dotnetcore 3 - because that supposedly will allow me to go back to EntityFramework 6. Yeah, core, all nice and shiny. But with bugs like that:
#12089
being pushed and pusehd - ah - "does not work" is it. I run odata as front end, and users are expecting to be able to put all kinds of queriesi nto the backend and I basically open a bug everytime someone updates a front end call. Not getting patches out - and I am expected to ship an update every two weeks, you know - for months (2.1.1 release shown as 2 months ago, with no newer even PREVIEW available on nuget) really blocks. And I am sure I am not alone.

So, please, get a release plan going that is more than "ah, yeah, we work on 3.0 now and the rest we do not tell you". The best I could find at aspnet/Announcements#308 - and the oint "reduce regressions" makes me cringe because I literally can not move significant functionality to dotnetcore because efcore just does not work and generate vlaid sql etc. in those scenarios. Yes, please. Except - 2.1.3 already has fixes that come when?

As a user, I would expect to have a bug fix release plan (even if as simple as "every month" and to be able to (a) track in which release my bug is fixed and (b) actually plan that this fix will be released. Thisis a core library - it is criticla for anyone trying to do non trivial database work.

[ajcvickers]

@NetTecture I'll try to answer your concrete questions as best I can.

With regard to servicing releases (2.1.3, 2.1.4, etc.):

• The EF team doesn't decide on the schedule for those, and generally doesn't get to decide when they are announced.
• There is a process around getting approval for bug fixes in servicing releases. This considers customer impact, risk of introducing a regression in the fix, whether there are workarounds, and so on. Again, the EF team doesn't decide on the "bar" for this, and the bar varies based on other factors. However, in general the bar for getting something into a servicing release is pretty high.
• The date that the branch closes for a particular release is significantly before that release happens. 2.1.3 is closed for new work, 2.1.4 is essentially closed also.
• Some servicing releases are even more constrained than others. 2.1.2 was like that, and hence nothing EF had met the bar.
• Nightly builds of servicing branches are available, but generally not pushed to NuGet. This is something we are working to improve.

With regard to 2.2, it is still planned and the published roadmap has not changed. It is, relatively, a smaller release, but we still have a significant amount of work scheduled for 2.2.

With regard to regressions and query quality:

• EF6 and EF Core are different technologies. While they share many of the same concepts and API patterns, the behavior can be significantly different. Of course, we strive to have a LINQ provider that is better than EF6 and can handle everything that EF6 can handle. That being said, it should be expected some things that worked on EF6 may not work in EF Core.
• Query is lacking test coverage. We are working on this on a few fronts, but it is not a small amount of work, and takes resources away from adding features or fixing bugs--one reason 2.2 is a smaller release. One part of this will be making easier for people to submit tests.
• It has become apparent that using OData causes certain query patterns to be more common than would be the case if the queries were written by hand. This makes it particularly prone to lack of test coverage.
• Certain aspects of the EF Core LINQ provider make it more prone to regressions--for example, automatic and deep client evaluation. Along with the test coverage, we are also working on a strategy to address this in the 3.0 timeline.
• Because of these longer running efforts around query, it means that many query issues have been punted out to 3.0. This was a difficult decision to make, but we believe that we need the query internals and testing issues to be resolved before continuing full-stream-ahead on query coding.

With regard to EF6 on .NET Core, this is planned for .NET Core 3.0. The intention is to make it easier for people to port applications to .NET Core without changing to a new technology. It is not really related to the Desktop effort in any concrete way. This may be a better solution for people like you with a complex existing app that uses EF6. However, it limits the app to only using features of EF6, and we do not intend to add any new big features to EF6.

[NetTecture]

@ajcvickers Well said, sadly it boils down to "rotten product, crappy update cycle, fuck off". No, seriously. Let me go through that a little.

• First, in the current form, EF Core is broken. Period. It works only in the most simple cases you can come up with. There are bugs open right now that are horrific. I Can take all your excuses for that - and hey are making sense - but not fixing those bugs as soon as possible meand the product is not working. If thigns fail the moment I make a join, repeatedly, then well, it is broken. Period. And I have such cases. I pretty much open a bug every time I write code for EfCore - never had that with the old 6.2 branch.
• Now, for updates. I really like how you try to tackle all that and go to a larger picture and all. But the sad relity is that there are those of us who actually do not work in lala land and have to ship. The sad reality is this:
• EF Core 2.1.1 is broken for anything but the most simple case.
• EF Core 2.2 will not be usable before December. Oh, preview , yes, but preview is not something I can acutally ship. And I have to ship every 2nd week.
• Now, you get wider and say that things will mostly get fixed in a 3.0 timeframe. Are you even ware that this means no shipping for another 9 months or so? Seirously, I LOVE The ide aof 3.0 - finally retiring the main ramework, still having WPF etc., but I have to shop every second week. NOW, not next summer. And I am not alone.

YOu basically tell people that the ONLY way to use asp.net in the modern form right now is in the form of using the proper "old" full runtme and then being able to use EF 6.2 - see, "works". Nice that you say - wait - ah - let me quote... "it limits the app to only using features of EF6, and we do not intend to add any new big features to EF6". This translates for most people like this: "it limits you to an ORM that works and doesn ot bulk ona simple join. It may not be innovative, but it WORKS".

And that is the problem. It is extremely frustrating not to see any fixes pushed out for a product that balks on prety much any use case. You know taht the way I use it now is having 2 code paths? And a decider in between. If the decider sees anyhing complex (join etc.) in the decision tree, it PULLS AL LDATA IN MEMORY AND RUNS THE QUERY AGAINST IN MEMROY. Ups. Performance sucks. But it WORKS. The moment I push a condition on a join down to EFcore - which is the case in 90% of my queries - I get funny side effects, stuff that ins unstable (breaks or not), stuff that is FIXED but hey, fixes re not published because - as you say it "you do not decide that".

Get out, f***k off and come back once 3.0 is out - not a strategy I want to follw, but one I may have to.

Now, one thing is funny here. You say:

"There is a process around getting approval for bug fixes in servicing releases. This considers customer impact, risk of introducing a regression in the fix,"

The way I see it efcore is broken right now. The risk for anyone outside trivial use cases is zero - or: it is "oh, some things acutally start working".

"That being said, it should be expected some things that worked on EF6 may not work in EF Core." - he way it looks to me that is anything that is more than a simple table select with a number of simple filter conditions. The moment you get more complex, you have a 90% chance of things just blowing. So, no, it is not "some things", it is "pretty much everything". Some of them are trivial. Some of them are fixed. Except the fix IS NOT PUBLISHED. And now fixes are pushed back because of "large impact" and that means waiting a minium of 3 (december for 2.2) to what - 9 monthy (summer 2019). NOT GOOD.

Btw., the idea of regressions is really laughable because for one simple reason. If a fix release introduces a regression, the consumer can always not upgrade. Done. But in the current state -the current strategy is grossly hambering adoption. EF Core is NOT EF 6.2 which is mature and generally works. It is a product that has brutal alrge areas that are not working an make it NOT a usable ORM at all.

Now, personally, I can POSSIBLY wing a 2.2 release - we are still in a stage where I can dare it, assuming 2.2 release builds are getting into better than nightly quality soon (ki.e. wekly preview or something - somethign where there is LITTLE less risk)l. But 3.0 is totally out. WAY to far out to "wing" it into production, as much as I look forward to it. But sadly, to quote you: "Because of these longer running efforts around query, it means that many query issues have been punted out to 3.0. " - "Dear customer, please do not use this product, there are no plans to acutally FIX anything for now, but the next major release, a year out, hopefully will be usable". Ouch.

Sorry if that got off as a rant. This is just me being between a Rock and a hard place.

[vslee]

Where are the other issues you have opened? Are they under a different GitHub username? Just curious as to the type of bugs you're running into.