Closed ErikEJ closed 1 year ago
It would be nice if we can use an older version if we don't want to update. i'm not sure if i can do this because extensions are updated automatically inside my VS.
How about persisting until 3.1 is EOL? Dec 2022 - https://docs.microsoft.com/en-us/lifecycle/products/microsoft-net-and-net-core
@mustafaelshobaky I will create a GitHub release with a .vsix file before I remove 3.1 support, you can use that and disable automatic updates @CaiusJard Yes, I am thinking about removing in November 2022
i will say yay
better to keep in sync with current supported release of core, if someone need 3.1 they can get an earlier stable release
ex; 5.0 should be dropped soon too
We still use EF Core 3.1 heavily in my organization, but are trying to plan upgrades before it reaches EOL. I don't see an issue though if you create the .vsix release on GitHub after EOL though, just in case we miss our target some.
Current (informal) usage stats from EF Core Power Tools:
EF Core 3: 13 % EF Core 5: 41 % EF Core 6: 46 %
@ajcvickers
@ErikEJ Realistically, some people will continue to use unsupported versions pretty much forever. However, I think it's reasonable to drop support when 3.1 goes out-of-support, or thereabouts.
We still use EF Core 3.1 in my organization and will continue to do so in the near future. And we use power tools for all our scaffolding needs so it is always nice to see new features and improvements.
@jyoti-kundani you will continue to get that for the rest of this year as minimum
I think the better question would be: Should the EF Core Power Tools support align with Microsoft's support for EF Core? If yes, then that answers this question, as well as the future questions you may raise around other versions.
@develorem Based on usage, I am not planning to drop support for EF Core 5 in May this year.
Hello @ErikEJ
In my opinion you should get rid of ALL options there that makes your tool a hell to maintain.
Like you know i made a stripped version of your tool where i just removed all EF instead of current. This simplifies a lot by removing at least 6 projects and custom build commands and so on ... Also i am ALWAYS moving it to current EF Core as launched by MS. Now my tool has 6.0.3 and it is happy about.
MS Changed the Long term support since .NET5, so i dont see why you should spend time to support outdated support at MS. EF7 + .NET7 from autumn will make EF6/,NET6 out of Long term support and so on ...
EF7 + .NET7 from autumn will make EF6/,NET6 out of Long term support and so on ...
Actually EF Core 6 is supported for 3 years.
Hehe, ok, in this case when EF7 will come you will add another option and another project / build tools and stuff. It just makes your life harder and it is too much democracy i think for a free tool.
Then why not to support EF Core 2 on .NET Core 2 and so on..
How i did it i started with your tool in EF Core 6.0.0. Then i moved it at every release, 6.0.1, and now to 6.0.3 and ensured that all my needed features works as they should. Easier to test and maintain that having to support plenty of old options. Just my remark there.
Otherwise the tool is GREAT and we than you very much for it as otherwise the EF Core was pretty unusable for me at least.
@CorsairRO Adding support for EF Core 7 will quite trivial. And the tool already uses 6.0.3.
EF Core 3.1 is the latest version which ik compatible with .Net Framework.
@TimKras Good point, I will take that into consideration
We're also on a .NET Framework 4.8 ASP.NET app and will be well past the end of this year. (Just upgraded from 4.72 to 4.8 today)
@KarlZ Given that you are a sponsor I will take that into consideration.
This is not currently planned, will revisit in furture based on usage numbers and the fact that 3.1 support stops in December 2022
FYI: This has now been done in the latest daily
@ErikEJ I don't think we've done anything on 3.1 this year. Thanks!
@KarlZ cool. I have also uploaded the current build so you can manually install that if needed
Query: customEvents | render piechart
9 % on May 19, 2023