Ecto 3.0 is out and stable API

ecto

#1

EDIT: since Ecto 3.0 final version is out, this post was amended to use the final versions in the instructions below.

Hi everyone,

We are glad to announce the release candidate for Ecto 3.0 is out. Just update your dependencies list as follows:

{:ecto_sql, "~> 3.0"},
{:postgrex, "~> 0.14.0"}, # or mariaex

We are covering the changes in Ecto 3.0 in a series of blog posts and there is also a CHANGELOG, so I would like to use the forum to talk about something else: the stable API announcement.

With the release of Ecto 3.0, I would like to announce that I finally consider Ecto to provide a stable API. This means no more new features, although we will continue providing bug fixes and updates. For everyone running Ecto in production, rest assured that Ecto will continue to be a well maintained project with the same production quality and polish that it has today.

A milestone reached

Ecto is one of the oldest projects written in Elixir. It started in 2013 and now we are almost ready to launch the third major version.

Ecto 1.0 was an important and exciting milestone due to the scope of the project in itself. However, Ecto 1.0 had some glaring flaws, both on how it forced developers to structure their code and in its implementation.

For Ecto 2.0, the community stepped in, pushing Ecto to a better direction and James Fish led the fantastic work on DBConnection, which made Ecto simpler, faster and more robust.

Ecto 3.0 is the consolidation of this work and of the efforts done by the community over the last 5 years. It took three major versions but Ecto itself and the ecosystem are mature enough that it should no longer impose major changes. Generally speaking, I personally start software with the intention of eventually “getting it done”, I am glad to have reached this milestone with Ecto.

Therefore, I am announcing that Ecto has become API stable. I will continue to update it and fix bugs, but no new features are planned nor will be accepted. Instead I plan to focus my energy on advancing the greater Elixir ecosystem.

The path(s) forward

Many people are passionate about the problem domain Ecto aims to solve. I hope this announcement gives many of you the opportunity and the push to explore the design space and come up with newer approaches and inventive solutions.

Alternatively, if you feel like Ecto should go beyond the current stable API and you would like to take Ecto towards new green pastures, that’s definitely an option too. Getting involved with the project maintenance is a good way to get started and learn the ropes.

Finally, I would like to recognize that Ecto is built on top of smaller projects, such as DBConnection, Poolboy, Postgrex, Mariaex as well as third-party adapters. Those projects will most likely also be the foundation of the projects to come. I want to thank their authors and maintainers for the amazing work throughout the years.

Many of the large open source projects, regardless if written in Elixir or not, depend on many small projects that are fundamental to that community. So I also want to remind everyone to look at their dependency trees from time to time and make sure to thank the people involved in those small projects that support the whole community.

For everyone running Ecto in production, rest assured that Ecto will continue to be a well maintained project with the same production quality and polish that it has today. We are proud that Ecto has currently zero opened issues and we plan to keep it that way. If you would like to help with the maintenance effort, contributions are definitely welcome too.

Have fun!


Your thoughts on advancing the Elixir ecosystem
Ecto 3 Info (RC is now out)
#2

Awesome :slight_smile: I (and workmates!) have been tracking the progress of Ecto 3 and are excited to use the new features … THANKS to everyone who works on Ecto, as well as its drivers (we use the postgrex driver extensively!). It is a fantastic bit of kit that makes common things easy and hard things possible …


#3

Hey @josevalim, do the ecto team plan to support additional databases, like Oracle, MSSQL, etc?

Also, what about the Mongo support that we “had” in Ecto 1.x series?

Nice work folks from Ecto team. :slight_smile:


#4

It is all up to the community. I know MSSQL is supported on Ecto 2 and it should shortly be updated to Ecto 3 too. We had discussions about making MSSQL part of the default Ecto.SQL offering, we will continue the conversation once things calm down after the release. For everything else, the support is done externally.


#5

Great news :smile:
Really looking forward to use the named bindings.
Thanks to the ecto team for the great work.


#6

I just want to say that I love how you are so direct and explicit about calling things “done” and moving on to focus on other areas of the Elixir ecosystem.

I take it as a healthy sign of maturity.

Good job, and thank you to everyone who has contributed to Ecto.


#7

Well done and congratulations to everyone who has worked on and supported Ecto over the years :purple_heart:

And special thanks to José, Chris and other prominent figures in the community who take the time to keep us updated and informed with posts and announcements like this - thank you :heart:


#8

Thank you to everybody that contributed to Ecto and the underlying libraries. I’ve watched the changes and features fall into place and absolutely love how complete the feature set is. Most of the fragments and escape hatch SQL my team has been writing is now possible with the query DSL.

Wonderful to hear the sentiment that sometimes software is finished. Stable tools are a beautiful thing.


#9

Exactly this. I was going to comment something along the lines, but your comment summarizes my thoughts very well.

This is a sign of maturity, there is no need to provide features for features shake.
Ecto has a mature and stable API. Tested in lots of different applications and built upon the knowledge and lessons learnt of similar systems in other languages and frameworks.

With the improvements on Ecto 3.0 it will only keep getting more and more polished. Great work and congratulations to all the team and those working on the underlying libraries :bowing_man: .


#10

#11

I really appreciate this direction, Elixir’s core as well as it’s core libs feel very stable, even more so for a relatively new language - that saves a lot of maintenance work. Great job!


#12

3 posts were split to a new topic: Your thoughts on advancing the Elixir ecosystem


#13

MSSQL is supported in Ecto 2 through tds_ecto or mssql_ecto, where mssql_ecto performs much better in our experience.

There is a however caveat when using parameterized queries, which seems quite undocumented:

This query will fail in both tds_ecto and mssql_ecto
sql = "select * from users where name = $1"

This will work in tds_ecto
sql = "select * from users where name = @1"

This will work in mssql_ecto
sql = "select * from users where name = ?1"


Your thoughts on advancing the Elixir ecosystem
#14

José,

I am not certain that I understood your announcement correctly. First you say

Therefore, I am announcing that Ecto has become API stable. I will continue to update it and fix bugs, but no new features are planned nor will be accepted.

but then you say

Alternatively, if you feel like Ecto should go beyond the current stable API and you would like to take Ecto towards new green pastures, that’s definitely an option too. Getting involved with the project maintenance is a good way to get started and learn the ropes.

which seem in contradiction.

Put simply:

Is there any chance for an Ecto 4.0 to happen in the future or not?
Or there will be only Ecto 3.x maintenance versions?

Thanks


#15

If somebody else gets involved in the project maintenance, at some point we will be glad to hand off the project and it will be up to them to steer it as they prefer. Unless that happens, there will only be maintenance versions.


#16

why not announce you are stepping back from ecto development and interested parties should express interest in continuing development (or ask them to fork and rename if you want to retain control of ecto itself)? pronouncing that ecto will accept no new features makes it seem like you are shutting down development to everyone


#17

Forking and/or renaming is always an option because of the license Ecto uses. The core team will maintain Ecto as it is today. The last paragraphs of the post outlined options for people that want to continue to add features to Ecto, what do you think is missing there?


#18

I thought the sentence below was pretty clear in that regard:

Personally I love the direction. Ecto does everything that it needs to right now, it doesn’t need to get bloated.

How I understand it is that its feature complete now and if someone needs a specific use case, they can write a plugin, or fork and build on it. And if a new general use case appears in the future that should be added to ecto it will be added after discussion.


#19

if someone wants to add a new feature to ecto what’s the process? fork? ask to take over maintenance? make a pull request despite jose announcing no new features will be considered?


#20

The options are forking or contributing to Ecto to the level where the team thinks you can take ownership of new features or eventually the whole library.