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 .
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!
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?
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.
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
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?
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.
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?
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.
The only reason I did not announce I am stepping down from Ecto is because it still has to be maintained until said parties step up. But if you feel like that is not necessary, I am ok with not having to maintain it either.
Are there actually missing features you‘d like or need? If not, I feel like it‘s not worth having this discussion right now - often times people worry about things that eventually will never happen.
No, it is not possible yet, as we are collecting feedback from people building stuff using the private APIs - which is not ideal and it will break but at least it is possible. If you can start a new topic here, explaining what you are doing right now, the pros and cons, it can help push the conversation forward. I believe @talentdeficit is interested on this too. This particular item is work that has not been finalized yet.
Ah never mind, I’ve figured it out. From the Ecto 3 Changelog:
Locked migrations
Running migrations will now lock the migrations table, allowing you to concurrently run migrations in a cluster without worrying that two servers will race each other and run migrations twice.
In order for this safer migration mechanism to work, at least two database connections are necessary when migrating. One is used to lock the “schema_migrations” table and the other one to effectively run the migrations.