Closed mariuswilms closed 5 years ago
Any preferences for renaming lithium\core\Object? BaseObject or LiObject are the first that spring to mind. Possibly InstanceObject to counterpoint StaticObject. I'm looking into this currently, with a simple rename that can be changed to whatever you prefer, with search/replace.
A link to your current submission guidelines would be appreciated.
The Object base classes are planned to be removed for 2.0; they are currently in the process of being deprecated, see here https://github.com/UnionOfRAD/lithium/issues/1251. The corresponding branch is here: https://github.com/UnionOfRAD/lithium/tree/struct/deprecate-object
The two remaining tasks on that issue block the full deprecation of the base classes in 1.2 and thus the removal of the classes in 2.0 (features need to be deprecated before they can be removed or changed).
Would you like to help out with solving the last remaining two tasks? Your help would be very appreciated, see if this is something for you. Otherwise I guess this will take us more than 6 months.
The deprecations will need to be be submitted as a PR against the struct/deprecate-object
feature branch. After that we can continue to merge and remove in 2.0.
The remaining tasks can be found in the original issue text.
Hi @davidpersson. It was my intention to get branch 1.2 running with PHP 7.2 first (with the class rename and other required changes), as it is needed for people that have already upgraded to it, and then continue with the other tasks as noted in the changelog (refactoring calls to certain Object methods to use the alternatives in Libraries, MergeInheritable, Model, Validator, etc.).
I've refactored use of each() which is also deprecated in PHP 7.2 and have mostly done the Object -> BaseObject switch, just have a weird test failure blocking me - https://travis-ci.org/niel/lithium/jobs/383513373
Getting 1.2 branch working is a high priority for me as I have users that have already upgraded to PHP 7.2, with others planning to do so shortly. Once, that is done I'd be more than happy to look at those last two tasks and see if I can tackle them, in fact I'll take a look tomorrow to get an idea of them, to see if it might be easier job ;-) Any suggestions where I might find any documentation on changes to be made?
Just took a look at the struct/deprecate-object branch and it seems to be failing on several tests with PHP 7.1. See https://travis-ci.org/niel/lithium/jobs/384243684 I won't be able to work on it unless those are cleared.
I've refactored use of each() which is also deprecated in PHP 7.2 [...]
Usage of each()
has already been removed in 08d38b2312fbd556249776c7f974b2ad6eba6e47
It was my intention to get branch 1.2 running with PHP 7.2 first (with the class rename and other required changes), as it is needed for people that have already upgraded to it, [...]
Getting 1.2 branch working is a high priority for me as I have users that have already upgraded to PHP 7.2, with others planning to do so shortly. [...]
Totally understandable when you have clients, that need the support now. Under time pressure I'd suggest to do a quick rename in a fork. However I don't think an ad-hoc solution is good enough for the official repository.
For the future of the framework it's important that we now focus on 2.0, to get it out the door together with i.e. the new mongo driver. Thus I've decided that the 1.x series will be compatible only up to PHP 7.1.
2.0 will not break all the things, and there are "just" 2-3 tasks left for solving *Object, so I'd suggest you to consider 2.0 as a next upgrade target for your purposes and we can fix the remaining tasks.
Just took a look at the struct/deprecate-object branch and it seems to be failing on several tests with PHP 7.1. See https://travis-ci.org/niel/lithium/jobs/384243684 I won't be able to work on it unless those are cleared.
Sorry I've not been precise enough with information on the purpose of the branches. The deprecate-object
feature branch is currently unstable and contains work in progress. I've made it public so contributors who'd like to help have (draft) code to begin with.
The 1.2 branch is stable, when tests are failing there, please file an issue.
Apart from the PHP 7.2 support, how functional is 2.0? Is it feature complete with regards to 1.1/1.2? Is there likely to be much in the way of changes to the API?
Apart from the PHP 7.2 support, how functional is 2.0?
2.0 is fully functional and all tests are passing.
Is it feature complete with regards to 1.1/1.2?
2.0 is still in development and not yet feature complete. We aim for a release this year, so there on the other hand isn't the chance to put too much in it.
Is there likely to be much in the way of changes to the API?
Yes, that major release will allow for breaking changes. We plan to exercise this right carefully, i.e. we prefer changes that don't require modifying the manual. The release gives us the chance to clean some things up (see above) and not planned as the big bang release.
Is there any progress on this as of April 2019?
@JasperTey Last commit to the branch was c4ef68e, which was 30th. July 2018, so I would say no.
I'm interested in doing whatever I can to help this migration. PHP 7.3 is already four months old and 7.4 is on the horizon for 4th Quarter 2019. PaaS like Google App Engine support 7.2 as a minimum.
Is the todo list in this issue up to date? Looks like the 2.0 and deprecate-object branches are stagnant.
Partial PHP 7.2 support has been enabled for 1.2, in 68932bc6fbe39bd0ed1ce926eae4acab969f44df. Please see the notes regarding usage of the base classes in the changelog.
PHP 7.2 has been released in the beginning of this year and now seems stable enough to be officially supported. Solving this issue involves re-configuring the CI environment to take 7.2 into account, than go ahead and fix all issues that appear.