Should Idiorm be marked as end of life?

[henryruhs]

@treffynnon It would be fair to let new developers know that Idiorm is end of life and that alternatives should be considered for new projects as of 2020.

Maintainer Interest

From what I read in the issues, you are not using Idiorm by yourself and therefore lost interest. I think this is a natural thing for OpenSource and I don't want to judge you for that, but this usually means the end of a project as long you are not asking for a new maintainer.

Feature Complete

By it's definition means that no features will be added anymore, but from my point of view this does not include that modernizing the codebase is forbidden as the languages moves on.

This is a huge problem in communication as developers might have another understanding in this term as you have. There is no active development for years and this should be pointed out somehow.

Upcoming Support

PHP 7.4+ is not being tested on CI as of the outdated testing suite and breaking changes in PHPUnit with old PHP 5 versions. We are heading to PHP 8.0 and this library is not ready for it.

[treffynnon]

You raise some good points and I acknowledge that communication surrounding this could have been better on my behalf.

Unfortunately, I don't think that the status of the projects is simple as you or I would like. The two projects are not EOL, but whilst maintenance is continued any active development has ceased. To describe this in semantic versioning terms this means that only patch releases are allowed. PHP 5.2 support will always be maintained in Idiorm and Paris to support developers stuck on legacy environments.

You're correct to say that I am no longer a user of Idiorm and this has been true for a long time. I have also been through a number of changes personally that have taken precedence over any open source maintenance and not just Idiorm. This has meant that there have been times when response times to new issues or pull requests have not been as swift or considered as I would have liked.

It has been 10 years since Jamie first wrote Idiorm (a very long time in the software world) with Paris following along soon after. He never expected it to be as popular as it has become so was very pleasantly surprised by the reception it got. This is back before composer was around and it was very attractive to PHP library users to be able to just drop one file into their project as a dependency.

When I picked up the maintenance of the project; time had moved on and Idiorm was lagging behind. So, I moved all the documentation into better format and setup the project to publish to packagist so that composer installation was possible.

Around this time Jamie and I discussed the appetite for an API rewrite because newer PHP versions brought features that would mean the library could be cleaner. At the same time the code style Jamie had used looked a lot like Python PEP8, which the PHP PSR totally disagreed with.

Given that Taylor Otwell had already released Laravel and its associated database tooling - Eloquent - we decided that Idiorm should remain focused on supporting legacy projects. Eloquent had used many of the ideas that Idiorm had brought to the PHP world, but it was written in a modern PHP style. It also had investment behind it with a sponsored full time developer. Idiorm was never going to be able to compete with that or bring new ideas to the table.

In this way Idiorm was destined to support PHP 5.2 way beyond that end of support timeline for that PHP version. Ultimately, this meant that many project teams were able to use it to refactor old code under restrictive server environments. It was even used in embedded applications due to its lightweight nature and broad PHP version support. This is the niche of the Idiorm and Paris projects.

Where Idiorm could be patched to support newer versions of PHP or a PSR it was updated. Future compatibility with PHP versions is never guaranteed with any open source project. It would seem that Idiorm is now at the point where support for newer versions would require changes to the API - this work will not be completed.

Idiorm is not modern or widely supported by a big team of developers. Eloquent is. Idiorm will continue to support developers that are stuck on old versions of PHP, but will not guarantee support for future PHP versions. So, new projects or projects upgrading to newer PHP versions should take the opportunity to replace Idiorm with another database library.

I have been recommending Eloquent to people as a viable alternative for many years now. It can be used independently of Laravel almost as simply as Idiorm and Paris.

For more details on how to install it I recommend the Eloquent documentation over at the Illuminate/Database project repository and there are also the following higher level resources that may be of interest:

• https://medium.com/@kshitij206/use-eloquent-without-laravel-7e1c73d79977
• https://www.amitmerchant.com/how-to-utilize-capsule-use-eloquent-orm-outside-laravel/
• https://hub.packtpub.com/eloquent-without-laravel/
• https://www.codewall.co.uk/use-laravel-eloquent-query-builder-in-any-php-project/
• if you're also using Slim then this might be handy too: https://odan.github.io/2019/12/03/slim4-eloquent.html

The actual functionality/API of Eloquent is documented in the Laravel (version 7 as of writing) manual, which is user friendly in my experience: https://laravel.com/docs/7.x/database

Another option is to fork Idiorm/Paris or create an entirely new project of your own that has a similar API etc, but that isn't hamstrung by PHP 5.2 support.

I hope that I have managed to address your points and those of @CatalinFrancu in comments on #351 (comment) here.

That said I have been meaning to write a blog post covering all of this for sometime, but it keeps slipping to the back of my to do list. That post would be linked from the READMEs of both Idiorm and Paris with a tl;dr that made the status more explicit. Perhaps this response can form the basis for that and I can get sometime to actually finish it off.

[henryruhs]

Thank you very much for not acting defensive on this discussion. 10 years of usage is such an big deal in the world of open source and in terms of a software life cycle in general. Guess, this is the time to shout out for a massive thank you in the name of the community.

Option 1

I am not sure what the correct wording is... it might be "maintenance mode", "deprecated" or even "end of life" but the point is that we should warn developers that this software is not future proof.

Option 2

Have you ever thought about a call for a group of maintainer that could create a state of the art version of Idiorm? That being sad: I would be on board cause it does not make big of a difference where to put my time as I have to refactor the software using Idiorm anyway.

[treffynnon]

I agree that the current status needs to be more explicitly stated. I have not come up with the right terminology yet, but I think something along these lines displayed prominently in the README should work:

Idiorm and Paris are incompatible with PHP versions > 7.4

Support for future versions of PHP is not on the Idiorm and Paris roadmap as it conflicts with supporting legacy PHP versions. Maintenance in terms of security patches and bug fixes will continue - in semantic versioning terms this means patch release only.

Why?

Idiorm and Paris have enjoyed a long life and powered many applications over the years. For a longtime they have been considered feature complete with a final API and in maintenance only mode.

Support for PHP 5.2 in Idiorm was never to be removed, so this prevents many changes to the library. Patches have been completed to maintain support for newer PHP versions. Unfortunately, since the arrival of PHP 7.4, it is no longer possible to do this without modifying the library's API. This means that support for future versions of PHP is very unlikely - Idiorm and Paris will not accept breaking changes to facilitate it.

Idiorm and Paris will be maintained with security patches and bug fixes, so you can continue to use them on legacy PHP versions, but now is a good time to consider a migration plan to another database library.

What should I do?

If you're starting a new project:

It is not recommended that you use either Idiorm or Paris in new projects.

I recommend that you use the database library from Laravel as Taylor based it on Idiorm when he wrote it. This means that many of the same ideas are present there, but it is more actively maintained and has a more modern code style.

For current Idiorm or Paris users:

You can continue to use both projects as they will continue to receive security patches and bug fixes. When you upgrade PHP they may no longer be suitable for you anymore.

At this point you can either use another database library such as Eloquent from Laravel (see If you're starting a new project above) or you could decide to fork Idiorm and/or Paris to patch them with your own modifications.

What do you think?

As for option 2 - this was considered, but Jamie and I have discussed this at length many years ago and decided not to for various reasons. Chief amongst these reasons was that neither library needs more features - they are feature complete and have been for a long time. They were never intended to be all encompassing libraries like Propel or Doctrine and this was core to their original appeal to many users.

It is sad when projects are artificially limited by factors like these, but Idiorm and Paris always had a core philosophy to remain small and maintain legacy support. Legacy support was the niche/difference factor after Composer and Laravel came along.

Suddenly, installing libraries became really easy with Composer, so the fact that Idiorm is just one file you can drop into a project was no longer important. Eloquent brought a modern API and wide adoption to the ideas Idiorm and Paris had shared, but lacked legacy support.

Continued support of newer PHP versions would require breaking API changes - users would need to update their projects to match this new API. Given that this refactoring work would be required anyway it makes sense that a migration to Eloquent occurs instead.

Either way you have to refactor your code, but by migrating you benefit from a similar API, larger community, active development, more maintainers and community documentation through blog posts etc.

If you need legacy PHP support use Idiorm and Paris - if not there are better alternatives - chief among them, in my opinion, is Eloquent.

Idiorm and Paris will not be seeking new maintainers. Of course, people are free to fork the projects and make any changes they like under a different name - a link to any of these could be added to the Idiorm and Paris READMEs so user's can make up their own minds too. Forks have existed in the past too like Granada and GranadaORM.

All this is to say, that option 2 has been considered and will never be enacted.

[otobio]

@treffynnon Having read your comments, I will like to urge you to reconsider the reasoning for adding further features to idiorm or possibly wanting to mark idiorm as EOL (End Of Life).

Some of the reasons you gave are as follows, and why they do not really add up;

Eloquent had used many of the ideas that Idiorm had brought to the PHP world, but it was written in a modern PHP style

Your use of the term "Modern PHP Style" here is vague, but i assume you refer to ID (Idiorm) following the PSR specs.
Please, let this be clear, these specs are not a "Mandatory" requirements for any project. PSR is not a PHP requirement, rather is a set of PHP community tips and agreeables for writing composable project.
Therefore, it is not required for idiorm to follow them in any/all capacity.

Idiorm was never going to be able to compete with that or bring new ideas to the table

It already did. As it is a viable alternative to many non-existing query builders for mysql out there. And it works on PHP 7.4.

Note: It might seem like the vision for ID is forgotten, I think it aimed as a simple, mysql query builder. @treffynnon I suggest it be maintained in this capacity.

Ultimately, this meant that many project teams were able to use it to refactor old code under restrictive server environments. It was even used in embedded applications due to its lightweight nature and broad PHP version support. This is the niche of the Idiorm and Paris projects.

And nothing in this niche prevents it from being used in PHP@latest or PHP@future. It is still been used in this capacity and larger.

Idiorm is not modern

What does this even mean, about time we focused on what really matters. Idiorm works on the latest PHP version.

I have been recommending Eloquent to people as a viable alternative for many years now.

It might be an alternative, but Eloquent's target is larger, it supports multi rdbms vendor i.e postgres, mysql, sqlite etc. It houses concepts focused for laravel framework development (All PHP developer do not all share such ideas). Among other features.

Idiorm is a simple Query Builder compared against Laravel DB query builder for Mysql. Let it continue in this capacity. Many solely and continue to use Mysql in production. Lets maintain the focus there.

My Appeal: Please, lets not identify PHP@latest or PSR as the reason for stalling further maintainance on this utility library.

Final thoughts

Documentation in my opinion, is the most important thing in any project. idiorm has a good documentation (There is always room for improvement, by way of more examples of usage, surely.).

There are several progression path to reviving this simple but very useful tool.

• Achieve feature parity with similar project like Laravel DB query builder. Which is essentially what idiorm is; A Query builder.
• If you have got no time to work on this, create a feature wish list of usefuls that can be added to this query builder in the context of its offering, and you will be surprise that PR's will flow in.
• Understand that the whole PHP community is not what is Trending.
• Heck i checked if maintenance was still on because idiorm was missing a basic update feature without having to, first do a select then orm->save()

[henryruhs]

@treffynnon That draft looks good and quite honest to me. We should do it that way...

@otobio Sorry, I have the feeling you are not understanding the state of this project. The point of this issue is to inform developers that Idiorm is not future proof. I found this super sad also...

[PhilipMwangi]

Currently using Idiorm on PHP 8.1.7 and all is working well as of now. For those interested in compartibility overview.