Skip to content

For php7.2 #264

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

Closed
wants to merge 8 commits into from
Closed

For php7.2 #264

wants to merge 8 commits into from

Conversation

okashitay
Copy link

Overview

Issue #255

Pull Request OK?
This pull request works with php 7.2 or higher.

Please use ver.1.3.5 for PHP 7.1 and below.

@okashitay
Copy link
Author

Sorry, I was not reading the document
https://wiki.jasig.org/display/CASC/Developing+phpCAS

I will read it now.

@adamfranco
Copy link
Contributor

Hi @okashitay , thanks for starting on this PR! One thing I'm a bit unclear about is which changes are 7.2-only and break usage on PHP 7.1. I know the latest Red Hat Enterprise Linux 7 and CentOS 7 are still shipping with PHP 7.1, so while it will be be worth breaking backward compatibility with PHP 5.x soon, I'd rather not break BC with PHP 7.1 unless there are significant demonstrable benefits.

@okashitay
Copy link
Author

Hi @adamfranco ,
thank you for the message.
We will respond so that it can operate even in PHP 7.1.
Please wait for a while.

@doMynation
Copy link

doMynation commented Apr 10, 2019

Hey, firstly, thanks to all the contributors on this project. We've been using this library for years where I work.

If you don't mind me asking, what's the status for this PR? Has it been abandoned? We're migrating to PHP 7.2 soon and we're worried that phpCAS might be a blocker. I couldn't find a mention of PHP7+ compatibility in the documentation. If anyone could give me some pointers I'd greatly appreciate.

@phy25
Copy link
Member

phy25 commented Apr 10, 2019

Hey, firstly, thanks to all the contributors on this project. We've been using this library for years where I work.

If you don't mind me asking, what's the status for this PR? Has it been abandoned? We're migrating to PHP 7.2 soon and we're worried that phpCAS might be a blocker. I couldn't find a mention of PHP7+ compatibility in the documentation. If anyone could give me some pointers I'd greatly appreciate.

Hi @doMynation are you experiencing issues in PHP 7.2? Please see #255 because it seems that compatibility issue has been resolved.

@doMynation
Copy link

Hi @doMynation are you experiencing issues in PHP 7.2? Please see #255 because it seems that compatibility issue has been resolved.

Thank you for the prompt reply. I am not experiencing issues yet, I was mostly wondering (for my own peace of mind) if PHP 7.2 was officially supported.

@@ -37,7 +37,12 @@
* @license http://www.apache.org/licenses/LICENSE-2.0 Apache License 2.0
* @link https://wiki.jasig.org/display/CASC/phpCAS
*/
class CAS_Tests_Cas20AttributesTest extends PHPUnit_Framework_TestCase

require_once dirname(__FILE__) ."/../../../vendor/autoload.php";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These autoload requires are not necessary?

@@ -14,7 +14,7 @@
"ext-curl": "*"
},
"require-dev": {
"phpunit/phpunit": "~3.7.10"
"phpunit/phpunit": "~6.5.7"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is PHPUnit 7 better? (PHPUnit 8 only supports PHP7+, which is not good here)

@jdufresne
Copy link
Contributor

Rather than maintaining Autoload.php, is there any interest by the project maintainers in moving towards the PSR-4 autoloading convention instead?

If there is, I could give it a shot and it would move the package towards modern PHP community idioms.

@phy25
Copy link
Member

phy25 commented Jan 15, 2020

Rather than maintaining Autoload.php, is there any interest by the project maintainers in moving towards the PSR-4 autoloading convention instead?

I would say this will need to be eventually implemented at some point in the future, but we just need to retain compatibility somehow..?

@phy25
Copy link
Member

phy25 commented Jan 20, 2020

Personally we prefer composer now, and this work is also covered by #332. I am going to close the PR.

Thank you for raising the issue and attempting to fix it though!

@phy25 phy25 closed this Jan 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants