Just to clarify, what you said was not offending. It is totally fine for you to voice your concerns.
However, it doesn’t change it is disheartening. Ecto v3.0 was a long term effort, there are so many good things coming with it, but everybody fixates exclusively on this one thing… and it is tiring. It is the kind of stuff that makes you stop and think: why am I doing all of this work anyway?
Yes, docs will stay in Ecto. The ecto_sql is more about moving all adapter implementations out of Ecto. If you want to use MSSQL with Ecto, you need to bring the adapter, right? So now you need to do that for PG/MySQL too.
EDIT: I won’t be getting notifications from this thread. If somebody has implementation concerns about any of the breaking changes and they want to make sure it will be seen, please move the discussion to the issues tracker. Thanks.
I hate breaking changes. Ecto 1 -> 2 was a big headache for me. I guess I am totally going to use pure sql or :mnesia. Although evolving to a major piece of tool requires some breaking changes, but I think using backward compatible library in a mission critical production is a necessity.
To compensate this I would like to say that I’m in another group which (at least for now) is fixating exclusively on others changes (mentioned in query improvements) such as: Better join composition with named bindings and Database prefixes and index hints which in some cases would be really powerful change. Hope your heart is now soothed a bit. :
btw. Are named bindings finished already? I have tried them one time and had an compilation error when trying them with few inner joins, so I used old way thinking that it’s not yet finished …
Do you have any plans for first release candidate? Some changes are really important, so this time I could give some feedback really soon. There is really big chance to use latest version in our prod environment.
Ecto 1 to Ecto 2 was definitely painful because it provided an overhaul on how to structure your code. But the breaking changes in Ecto 3 were kept to a minimum and a lot of work was done for such. As a maintainer, it would be much easier for us to just break the code.
If you feel going through a handful of breaking changes in Ecto 3 is more work than writing SQL queries by hand, coming up with your own rules to structure code and probably writing your own data management code, then by all means roll your own.
Otherwise, if you want your tools to get better, faster, more resilient, etc, then you need to accept some breaking changes will come along the way. You can either get involved in the project to make sure those changes are kept to a minimum or hope the maintainers were kind enough to do the work for you.
It should be complete now. If you find any bug, feel free to report them!
It was meant to go be out this week but since Phoenix released a RC, we decided to postpone for next week. For all purposes, it should be ready. @wojtekmach has even done a PR to update Hex to Ecto 3.0 and everything seems to look good.
We will definitely appreciate the feedback from people trying it out!
Progress trumps minor (even major) breaking changes any day of the week for me
I think many people have come to Elixir and Phoenix in pursuit of something akin to perfection; a better way, and we love that José and Chris and the core teams of the various projects in the community (and even going back to Erlang with Robert, Joe and Mike) had a relentless focus on doing what they felt would represent the cutting edge in an as accessible as possible way.
Although Elixir and Phoenix (and projects like Nerves and Scenic) will I’m sure mature very nicely (you could argue most already have), I can’t ever see them stagnating, because it seems to be in the blood of those involved to keep introspecting and evolving