Why would one chose zf1-future over zf1s or any other fork of Zend Framework 1 ?

[fredericgboutin-yapla]

Legit question raising from #226 (comment)

We are in the process of selecting a fork of zend framework 1.

Is there any clues people like me can get in this situation, i.e. to help me choose between zf1s and zf1-future? Most notably why / how zf1-future is better suited?

Thanks! 🙏

[glensc]

how should one know what is best suited to you if you don't describe what you need?

[fredericgboutin-yapla]

At minimum we need a fork that supports recent PHP versions and that is virtually 100% back compatible with the original framework. Basically we need a "modern" drop in replacement.

Since both forks seem to cover these core requirements, I'm left wondering why we should choose zf1-future over the other forks.

I suppose the contributors / authors have already implemented some extra stuff which I'm not aware of, and maybe there is some sort of implicit roadmap. I think the reasoning here is probably to better understand what this project means by "future" when talking about zf1.

Finally, I guess we have to be realistic here about the fact that zf1 is a dead framework with only a few people still using it by necessity. This means that probably, at some point, we may need to contribute or take the project maintenance in our own hands. In this regards, the structure of the project, the CI/CD, unit testing, code lint, etc. are all determining factors to consider about the fork we are choosing right now.

[glensc]

zf1s tries to maintain compatibility with 5.3-8.0, written in it's readme, zf1-future does not, it has 7.1 as min requirement in composer. zf1-future is more relaxed about merging things in so, some things may be broken for others, zf1s on the other hand takes long to get changes in as there's only one person who can merge things. and he doesn't merge broken things. and he's busy too.

aside other things, I personally like and use zf1s because it provides composer packages for component split, zf1-future does not provide package split.

[glensc]

also, another point of zf1s package split, is to be component-based, so you could gradually replace zf1 with active zf projects or similar components.

[fredericgboutin-yapla]

I have fears with the package split leading to the "monorepo" practice. The unit tests are in the monorepo and are the one that ensure compatibility on different PHP versions with a matrix build - which is great BTW.

In a situation where we would need to "fork" zf1s because reasons, it would be kind of a nightmare to fork every single package AND we would absolutely need to master the "monorepo" set of practices / setup.

In the mean time, I'm looking at zf1-future, it is a single repo, so way more easier / straight forward to fork.

About the unit tests, I'm searching the CI and I don't see them run at all so I'm really NOT sure if they are used. Therefore, how PHP compatibility is ensured at the moment with zf1-future?

That's one of the initial questions I had that lead me to this thread TBH.

[Shardj]

@fredericgboutin-yapla

Glensc summed that up nicely. I'll add, there isn't really much of a road map. I'm pretty loose with PR merges as long as they don't break backwards compatibility on anything other than PHP versions. A few others have merge permissions too but it's mainly me merging here. There aren't really any feature changes, mainly just fixing deprecated or outdated functionality. Originally I created this repo to simply be a latest PHP version maintained copy of zf1.

[fredericgboutin-yapla]

@Shardj 🙏 and how do you ensure back compatibility on different PHP versions? Is there anything I don't see / miss in the CI / release process OR the project solely rely on popular feedback?

[holtkamp]

This: #257 (comment)

When trying to phase out ZF1, it is nice to only use the components that are still required, so I used zf1s and was quite happy with it.

To reduce the number of deprecation messages when using PHP 8.1, I switched back to a "complete" ZF1 package as offered by zf1-future, causing an increased amount of unused files to be downloaded and deployed to the production server.

@Shardj did/would you consider also using a package split so each component has its own repository? Probably a LOT of work though, which might not be justified for a deprecated framework...

[Shardj]

@fredericgboutin-yapla it relies on feedback, there aren't any bells and whistles to detect issues other than the syntax checker.

@holtkamp this repo has always been intended to be a straight up drop in replacement to zendframework/zendframework1, it's a convenience which is a large part of why I think zf1-future sees more activity than zf1s. I don't see this project going the same way as zf1s and splitting the packages, although I can appreciate that the waste of space from unused components is an annoyance.

[fredericgboutin-yapla]

@Shardj 🙏 and how do you ensure back compatibility on different PHP versions? Is there anything I don't see / miss in the CI / release process OR the project solely rely on popular feedback?

I suppose there are different ways to address this problem other than splitting into multiple repos, though I suppose we could automate the process following the spirit of maintaining shim repos. Otherwise, this tool seems interesting, https://github.com/liborm85/composer-vendor-cleaner so maybe we could come up with a certain set of definitions one could use to exclude some modules. I don't know. Only ideas at this point 😉

[glensc]

I'm kind of confused between your statement and the actual README which says in caps and bold: "Zend Framework 1 now for PHP 8.1!"

which project are you referring here to? i was speaking of zf1s, and the text I copied it's description:

• https://github.com/zf1s/zf1

from it's changelog, I don't see any 8.1 changes merged:|

• https://github.com/zf1s/zf1/blob/1.14.0/CHANGELOG.md

In a situation where we would need to "fork" zf1s because reasons, it would be kind of a nightmare to fork every single package AND we would absolutely need to master the "monorepo" set of practices / setup.

i don't understand the statement, the package split repos are readonly, you still need to contribute via main monorepo, (which as you noted), includes the tests and ci. the split repos are created because how packagist works. if packagist would allow to publish packages from monorepo, the git repos would not needed to be created. so, the monorepo exist only for development, as a user you just use split repos from packagist.

[fredericgboutin-yapla]

Oh, I understood it the other way around about monorepo. Thanks for the clarification!

zf1s tries to maintain compatibility with 5.3-8.0, written in it's readme, zf1-future does not, it has 7.1 as min requirement in composer

Yeah, I modified my original statement after I double read your message. I thought you were saying zf1-future only supports PHP 5.3-8.0 like zf1s, excluding 8.1. Sorry for the confusion and misunderstanding on my part.

[fredericgboutin-yapla]

Here is something I didn't fully realized when I compared zf1s and zf1-future - zf1s/zf1#128 (comment) - i.e. zf1s is NOT a true drop-in replacement to zf1 which has its set of consequences inherently attached to it.

I think I'm going to close this issue but before that, here are the conclusions we came with and our plan moving forward:

1. zf1s seems more mature in its way to deal with PHP compatibility and testing / quality software overall. zf1-future has a travis-ci definition but there's no access to its pipeline nor does it fully support php 8.x at the moment -

   zf1-future/.travis.yml

   Line 13 in 7b57530

   - php: 8.0

   So from a quality perspective, zf1-future is lacking compared to zf1s right now
2. zf1-future supports only PHP 7.1 up to 8.1 when zf1s supports PHP 5.3 up to 8.0. The latest version supporting PHP 7.0 is 1 year old and you must fix the version to 1.20.0 - Broken Zend_Db_Table_Rowset::current function #194 (comment). We cannot go from an unsupported framework to another one's version; it doesn't make sense.

So, since we are on PHP 7.0, and we definitely need some kind of support, it implies we will use zf1s... initially at least.

Since zf1s only supports PHP 8.0 and that version is supported up to novembre 2023 - https://www.php.net/supported-versions.php - it gives us a full year window to wait and see.

Will zf1s finally support PHP 8.1?

Will zf1-future step up its game in regards to verifying and validating better before release instead of "relying on feedback"?

We don't know, but in the mean time we will upgrade our version of PHP and if anything, we bet it will be pretty straightforward to switch from zf1s to zf1-future.

Thanks for everyone's input! 🙏 I suppose we'd close the issue after a final wave of replies (if there's one).

[glensc]

Will zf1s finally support PHP 8.1?

my 2ç:

1. you're asking from the wrong repository
2. nobody I know (at least looking at zf1s issues/pull requests) is working on 8.1 or 8.2
3. you could start contributing there yourself to improve the situation, however, that project needs more maintainers, current and only one of them is not healthy. I can volunteer to review things there since I've already contributed a lot there.

[fredericgboutin-yapla]

you're asking from the wrong repository

I'm not asking anybody. That was only an open question.

nobody I know (at least looking at zf1s issues/pull requests)

Say the man who literally created a pull request to improve the CI for that purpose, zf1s/zf1#129 😉

you could start contributing there yourself to improve the situation, however, that project needs more maintainers, current and only one of them is not healthy. I can volunteer to review things there since I've already contributed a lot there.

Yeah sure! That's something we thoughtfully considered when I talked about zf1s project structure with monorepo which initially looked more complex to contribute to.

If we are to encounter a bug that we must fix, we'd contribute back for sure.

[glensc]

Say the man who literally created a pull request to improve the CI for that purpose, zf1s/zf1#129 😉

check the timeline. that was created after my post here.