phalcon-orphanage
No documented security support
My organization is re-evaluating its usage of Phalcon. One concern which came up is security support for the version which some of our components are currently using, version 3. According to Phalcon 3.0's release announcement, version 3.0 was supported for a "long term" of 3 years (which was possibly until 2019-07-29).
However, there is no such information in the announcements of versions 3.1, 3.2, 3.3 or 4.0 (and there was apparently no announcement of 3.4). I cannot see any indication, in the documentation or elsewhere, that Phalcon has security support, even for version 4. I cannot find any security support policy or explanation of a version lifecycle.
We have been talking about that actually, and for v4 we are still not 100% if it is necessary. LTS or non LTS means nothing really in the real world, it is a reassurance factor that has no meaning.
Here is why I think this:
Say you have project A that has only one developer and never states anything about LTS etc. The developer/maintainer produces code and fixes things quickly and has been doing so in that project for decades (example xdebug). Does it matter that there is no LTS?
Project B states that they have LTS and all that yet maintainer A decides to leave, maintainer B also decides to leave and lo and behold the core team is gone, not that many people left to keep the direction of the project, PRs and issues left unanswered etc. Usually in cases such as this some people step up, fork the code and continue the project themselves. If that does not happen, what would the world LTS mean to the end user? Pretty much nothing. There are no lawsuits to be filed against people that were maintainers and for sure nobody can force anyone to do anything i.e. code for me or fix X for me.
Personally I am not convinced that we need to put that wording up there. So long as the project is active, responsive and moving forward, all should be ok.
I do however understand your dilemma where you need to present a case to people that potentially are not tech savvy. Not sure what the best solution would be. Add the LTS terminology for the sake of adding it or not?
As for the life of v4 version, we chose (for now) not to put a limit as to up to when v4 would be supported. This is one of the things we need to address but have been really busy putting everything in place that would help us maintain the project better. For now the only thing I can write is that v4 would be around for at least a year and support for PHP 7.2 would stop in 10 months (following PHP's release cycle).
Once we get our maintenance tasks streamlined (currently one release takes more than 3 hours) as well as our sprints, all this information will be announced with long life times so that the community can catch up and not have to upgrade their apps every X.
Thank you very much @niden
I am sorry if my report was not properly understood, I only used the term "long term" as a quote because Phalcon used it already. Obviously, "long term" is vague. The term "LTS" was coined by a project which made some releases with a reasonable support duration, and others with a very short duration. The term "LTS" helped distinguish releases with a reasonable duration from those without one. But since then, users have gotten harder to deceive, and the term is falling out of hype. As long as Phalcon does not have to satisfy a marketing department, I would in fact advise against usage of marketing terms.
I absolutely agree with your observations about LTS statements. In fact, a release on which there was no commitment about security support could in practice receive better security support than another one for which there was.
The only rectification I would make is that making a commitment to support does not put a maximum on the duration of security support. A commitment only sets a minimum. For example, if I committed to support Phalcon 4 for 5 years and a vulnerability is reported 4 years after its release, I have to fix it to honor my promise. However, if that vulnerability is only reported 9 years after the initial release, I am free to fix it just like I am free not to fix it.
To clarify our situation, the problem is not that I work for people who are not tech-savvy. The problem is that I work for a security organization. In the IT department, just the word "PHP" (and - to a much lesser degree - even just "free software") is already an orange flag. So seeing a third-party PHP extension written in C - in particular free software which is not created by a corporation - necessarily brings much mistrust. But people would still be less reluctant if the security track record was good and there was an important commitment to security support.
And you are right that a project's commitment to security support does not ensure vulnerabilities will be patched. Everyone in the project could decide not to honor their promise. Or they could all be unable to fix some issues. Or they could all die before the support period ends. But similarly, when I buy a monitor which has a 5-year warranty, nothing "guarantees" that it will be fixed if it breaks in 4 years. The manufacturer could go bankrupt before. So security support statements are relative, just like product warranties.
But to answer your question, yes, it does matter if there is no "LTS". If I have to choose between 2 products, one of which offers only a legal warranty, and another one which offers a 5-year warranty, I will certainly choose the latter, all other things being equal. And similarly, if I have to choose between 2 frameworks, one which makes no security promise at all or another one which promises 5 years of security support, I will also choose the latter, all other things being equal.
To come back to Phalcon's case, considering that it is a limited project, I think it would be best if a security support statement could specify who (individuals and organisations) is backing it. But given the information provided in your comment, for the moment, I think it would be best to simply document that Phalcon does not guarantee any security support.