Roadmap for components and frameworks

[visto9259]

This is more of a request than an issue.

It would be useful to have a roadmap for Laminas, Mezzo and API Tools components and framework.

As I was browsing through issues in various repos, the TC Minutes of Meeting (MoM), it appears that decisions are being made on the future status of components like making a component "feature complete" or "security only", etc. However, it is difficult to find out these decisions unless one stumbles upon a note somewhere in the README of repo.

For example, and if I am wrong you can correct me, I read in the MoM the API Tools framework would go into "security only" but there is no mention of that anywhere in the API Tools docs.

The roadmap should provide for each component and for each version of a component, its current status (active, abandonned, security, feature complete, etc.), the planned end of support/end of life, etc. If there are plans for a new major version, then it should also be on the roadmap with an expected release date. And any other information that could be useful. The roadmap should take into account the planned lifecycle of PHP versions.

As we develop applications based on these components, we also need some level of predictability in the availability of the components in order to make design decisions in the evolution of our application. Replacing a no-longer supported component by another component requires investment that need to be planned.

I understand that this needs work and effort from the maintainers and owners of each components but I also think that it would be beneficial to the user base and it would strengthen Laminas' image of being first-class framework.

I am open to further discuss this.

Thank you

[froschdesign]

The roadmap should provide for each component and for each version of a component, its current status (active, abandonned, security, feature complete, etc.), the planned end of support/end of life, etc.

A roadmap is for planing and so it can not contain the current status of a component, especially if they are no longer active. There should be a separate overview for the component status.

[visto9259]

A roadmap is for planing and so it can not contain the current status of a component, especially if they are no longer active. There should be a separate overview for the component status.

I agree that the term roadmap is not appropriate for the current status. The objective is to know where each component/version stands and what the future looks like.

[froschdesign]

In my opinion, a roadmap should definitely be discussed. I have concrete ideas for a roadmap and this can be put on the agenda for one of the next meetings.
An overview of the individual components that are in security-only mode can also be realised. Possibly even with the help of GitHub.

But we cannot write anything about the future of the individual components yet, because analyses and evaluations have to be done first.

[froschdesign]

Related to #154

[visto9259]

But we cannot write anything about the future of the individual components yet, because analyses and evaluations have to be done first.

This should be an on-going process as component owners evaluate the current status and lay down their plans for the future. I understand that this will take time to realize.

Minimally, knowing the current status would be a first step.

An overview of the individual components that are in security-only mode can also be realised. Possibly even with the help of GitHub.

I am curious to know how GH can be leveraged with this. I would use it for the LM-Commons repos as I have the same issue with current and future status.

[froschdesign]

I am curious to know how GH can be leveraged with this. I would use it for the LM-Commons repos as I have the same issue with current and future status.

For example, search by topic: https://docs.github.com/en/search-github/searching-on-github/searching-for-repositories#search-by-topic

Example: https://github.com/search?q=org%3Alaminas+topic%3Ahacktoberfest&type=repositories

[Xerkus]

I agree. Visibility for those decision is not good enough.

[PowerKiKi]

But we cannot write anything about the future of the individual components yet, because analyses and evaluations have to be done first.

But we can, and should, write that the status is not decided yet. Also every single status should be dated, so we can know whether the information is new and definitely up to date, or if it may be subject to change in the near future.

I'm thinking something like:

Package	Status date	Status	Comment
laminas-http	2024-02	security only	ok to be used with MVC, but consider using alternatives for other projects
laminas-log	2024-02	security only	consider migration to monolog
laminas-foo	2022-03	abandoned	migrate away as soon as possible
laminas-bar	2023-08	undecided

[visto9259]

I suggest to minimally add an "active" status for packages that are actively maintained.
If a package has more than one major version, like 2.x and 3.x, then the status should be by version as well.