-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explicitly declare supported PHP versions #158
Comments
/cc @NovemLinguae 👋 |
Thanks for the ping. Do any of the maintainers use this on Toolforge? If so and you've found it to be free of PHP errors and exceptions, maybe check what version of PHP your Toolforge is running, then add that to the table. For example, The motivation for my edit was avoiding unmaintained libraries from claiming to be compatible with the latest versions of PHP, when a deprecation or something could break it. Hope this helps. |
Not familiar with Toolforge. But of course, automated testing is better than one developer's limited experience. 😃 |
That confirms what I had in mind. Can you address the second paragraph in the opening comment above? I.e. what do you think would be the best way to indicate this within the project itself? |
Not familiar (enough) with composer or other GitHub metafiles to propose something there. I don't have any better idea than perhaps to more explicitly define the range of versions in the README. |
In this edit to the Wikipedia:PHP bot framework table page, it was pointed out that while we purportedly support PHP v5.3+, there are no guarantees of the upper bound of that range specification. We should encode this explicitly. That was already done in that table, but the information should be included in this repository.
If that is something that, say,
composer.json
, or some other metadata file, supports, then we should add the info there; otherwise, we should expand the information in the README from "It requires PHP v5.3 or newer" to something indicating the upper bound we have tested Wikimate to work with.That said, I suspect PHP version upgrades might retain backward compatibility with older code, which would make such an explicit upper bound redundant (though maybe still worth indicating). Do you know if that's the case, @Xymph?Edit: Nevermind, I didn't think about language deprecations.The text was updated successfully, but these errors were encountered: